ReDoS: How One Regex Can Freeze Your Whole Server

A username validator looks harmless:

if (!/^(\w+\s?)+$/.test(username)) return res.status(400).send('Invalid');

Send it the username "aaaaaaaaaaaaaaaaaaaaaaaaaaaa!" — 28 a's and a bang — and the request never returns. The regex engine tries every possible way to split those characters between \w+ and the repetition, the trailing ! makes every attempt fail, and it backtracks through billions of combinations. In Node.js that regex is running on the single event-loop thread, so this one 29-character string freezes the entire server for every user. That is a regular expression denial of service, and it needs no botnet — just one crafted string hitting one greedy pattern.

Why backtracking explodes

Backtracking regex engines match by trying a path, and when it fails, backing up and trying another. Most patterns have one obvious path. The dangerous ones are ambiguous — there are many ways to divide the input among the quantifiers — and when the overall match ultimately fails, the engine is forced to try them all. The three red-flag shapes:

• Nested quantifiers — (a+)+, (a*)*, (\d+)*. The inner and outer repetition can partition the input in exponentially many ways.
• Overlapping alternation under a quantifier — (a|a)*, (\w|\d)* where the branches can match the same character.
• Quantified groups next to overlapping tokens — (\w+\s?)+, .*.*, (x+x+)+y.

Add a suffix that can fail ($, a literal that won't be present) and you have the trigger: the engine explores the full exponential search space before giving up.

Where it hits

ReDoS lives anywhere a pattern meets attacker-controlled length:

• Input validators for email, URLs, usernames, phone numbers (email regexes are notorious)
• Log and user-agent parsers, markdown/BBCode renderers, syntax highlighters
• Third-party dependencies — a vulnerable regex deep in a library you don't control
• Anything applying a regex to a request body, header, or query string of unbounded size

The fix: bound the input, de-ambiguate the pattern, or use a linear engine

// 1) BOUND the input before it ever touches the regex. Exponential
//    growth only matters if the attacker controls length.
if (typeof username !== 'string' || username.length > 32) {
return res.status(400).send('Invalid');
}

// 2) REWRITE the pattern to remove ambiguity. The original
//    /^(\w+\s?)+$/ has nested repetition; this says the same thing
//    with no overlap between the pieces:
const SAFE = /^\w+(?: \w+)*$/;   // words separated by single spaces
if (!SAFE.test(username)) return res.status(400).send('Invalid');

// 3) Prefer a real parser for structured formats (URLs, emails):
try { new URL(input); } catch { /* invalid */ }  // no regex at all

The principles

• Bound the input first. Reject oversized input before matching. Exponential blowup is only exploitable when the attacker controls length.
• Remove ambiguity. Rewrite nested/overlapping quantifiers into forms where each character can only be consumed one way (\w+(?: \w+)* instead of (\w+\s?)+). Prefer real parsers for URLs, emails, and dates.
• Use a linear-time engine for untrusted input. RE2-backed engines cannot backtrack catastrophically — a strong default for anything touching request data.
• Audit your dependencies. ReDoS often lives in a library. Scanners and npm audit flag known-vulnerable regexes; keep them patched.

The one line: a regex applied to untrusted input is a denial-of-service risk unless it runs in bounded time — bound the length, kill the ambiguity, or use an engine that can't blow up.

Feel it firsthand in the ReDoS simulation: watch a short string drive an evil regex into billions of steps, then apply the linear-time fix and see it return instantly.