Sticky Situation: ReDoS in Tarteaucitron.js (CVE-2026-22809)

If there is one thing the modern web has in abundance, it is cookie consent banners. You know the drill: you land on a page, the screen dims, and a modal pleads for your data. One of the most popular libraries for handling this GDPR theater is tarteaucitron.js (French for "Lemon Pie"). It is generally a solid library, helping developers navigate the minefield of privacy laws.

But in early 2026, a sour note was found in the recipe. Specifically, in the integration code for issuu (a digital publishing platform). It turns out that while the library was busy asking for permission to track you, it was also vulnerable to a Regular Expression Denial of Service (ReDoS).

This isn't a server-side remote code execution that will burn down your data center. It is a client-side annoyance that freezes the user's browser tab faster than you can say "Reject All." It is a classic case of "it works on my machine" coding meeting the harsh reality of malicious input.

The vulnerability lies in how the library parses the issuu_id configuration parameter. The developers wanted to support legacy embed formats, so they wrote a parser to extract IDs from complex strings. Their weapon of choice? A regular expression.

Now, regex is like a chainsaw: incredibly powerful, but if you don't respect it, you will lose a limb. The specific pattern used was:

match(/d=(.*)&u=(.*)/)

Do you see the problem? It's the (.*). That is a greedy quantifier. It basically tells the regex engine: "Eat as many characters as you possibly can, then we'll figure out the rest later." In this pattern, we have two of them, separated by the literal string &u=.

When the input matches the format, everything is fine. But if you feed it a string that starts with d= and contains a massive amount of junk characters without the &u= delimiter, the engine enters a state of Catastrophic Backtracking. It tries to match the first .*, reaches the end of the string, realizes it can't find &u=, backtracks one character, tries again, and repeats this for every possible permutation of the string. The complexity skyrockets exponentially, pinning the CPU at 100%.

Let's look at the crime scene. The vulnerable code existed in the service definition for Issuu. It was meant to detect if the ID was a simple number pair or a complex query string.

// The Vulnerable Code (Before 1.29.0)
// Note the lack of anchors (^) and ($) and the double greedy capture groups.
 
if (issuu_id.match(/\d+\/\d+/)) { 
    issuu_embed = '#' + issuu_id; 
} else if (issuu_id.match(/d=(.*)&u=(.*)/)) { 
    // ^-- HERE DRAGONS BE. 
    // The engine must backtrack exponentially if '&u=' is missing.
    issuu_embed = '?' + issuu_id; 
}

The fix, implemented in version 1.29.0, was to stop trying to be so clever. The developers nuked the dangerous regex entirely and replaced the logic with a much stricter check for the simple format.

// The Fixed Code (Version 1.29.0)
// Strict anchoring. No wildcards. No backtracking hell.
 
if (issuu_id.match(/^\d+\/\d+$/)) { 
    issuu_embed = '#' + issuu_id; 
} else { 
    // Fallback behavior, much safer for CPU, though implies trust in input.
    issuu_embed = '?' + issuu_id; 
}

> [!NOTE] > While the ReDoS is fixed, the else block in the patch creates a potential new issue. It blindly prepends ? to the issuu_id. If an attacker can inject quotes or HTML into that ID, we might have traded a DoS for a Cross-Site Scripting (XSS) vector. But that is a story for another CVE.

Exploiting this is trivially easy if you can control the issuu_id. This might happen via a URL parameter that gets reflected into the configuration, or perhaps you are a content editor on a CMS using this plugin and you want to annoy your coworkers.

We need to construct a string that triggers the worst-case scenario for the NFA regex engine.

The Recipe:

1. Start with the prefix d= to trigger the second if condition.
2. Add a large number of characters that match . (anything).
3. Ensure the delimiter &u= is absent.
4. End with a non-matching character to force the full backtracking search.

The Payload:

d=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!

With just a few dozen characters, the browser will hiccup. Make that string 50,000 characters long, and the tab is dead. The regex engine will effectively loop billions of times trying to find a match that doesn't exist.

The mitigation is straightforward: Upgrade. Version 1.29.0 patches this vulnerability by removing the offending regex.

If you cannot upgrade (perhaps you're locked into a vendor-bundled version), you must ensure that any user-supplied input reaching the issuu_id parameter is strictly validated before it hits tarteaucitron.js. Use a strict allowlist of characters (e.g., ^[0-9/]+$) to prevent the complex payload from ever reaching the library.

This vulnerability serves as a reminder: Regex is code. It has performance characteristics and bugs just like C++ or Python. Treating it like a magic string matching box is how we end up with CVEs in cookie banners.