All DDoS Definitions
DDoS Testing Definition

ReDoS (Regular Expression Denial of Service)

A ReDoS (regular expression denial of service) is a Layer 7 (application) attack vector that weaponizes catastrophic backtracking inside a vulnerable regular expression, one of the resource-exhaustion classes a thorough DDoS test is built to exercise. A single crafted input string, often only a few dozen bytes, forces the regex engine into exponential-time matching that pins a CPU core for seconds or minutes. The damage comes from algorithmic complexity, not bandwidth: one request can burn the compute that a thousand ordinary requests would.

ReDoS: one short input, an exponential regex blow-up Crafted input ~40 bytes one request Backtracking regex engine pattern: (a+)+$ explores 2^n ways to match then fails, after minutes of work CPU saturated CPU core pinned 100% on one request Worker pool real requests stall Test measures the per-request CPU budget and backtracking limit that cap what a single input can cost. BlackNeuron
ReDoS: a short crafted input drives a backtracking regex engine through exponentially many match paths, pinning a CPU core while legitimate requests stall behind it

How catastrophic backtracking works

Most mainstream languages ship a backtracking regex engine. When a pattern contains nested or overlapping quantifiers, an ambiguous construct such as (a+)+$ or (\d+)*!, the engine can match a given input in exponentially many ways. On a string that ends up failing the match, it explores every one of those ways before giving up. Input of length n produces on the order of 2^n backtracking steps, so adding a handful of characters can multiply run time from milliseconds to minutes.

ReDoS: one crafted input pins a CPU core until a step limit ends the match normal matching cost CPU headroom time ordinary input matches in microseconds crafted input: exponential backtracking worker pool stalls, request rate flat step limit or timeout ends the match Illustrative. A backtracking engine can explore on the order of 2^n paths on a failing match; a linear-time engine or a step cap removes the exponential. BlackNeuron
Animated ReDoS: ordinary input matches in microseconds, then a crafted input drives exponential backtracking that pins a CPU core and stalls the worker pool while the request rate stays flat, until a step limit or timeout ends the match

The vulnerable patterns are ordinary-looking, which is what makes ReDoS common. Email and URL validators, log-line parsers, markdown sanitizers, and the rulesets inside a WAF itself are all frequent carriers. In 2019 a single regex with catastrophic backtracking took a large CDN provider's WAF offline worldwide for close to half an hour, a public reminder that the defense layer is as exposed to algorithmic attacks as the origin behind it.

Why it matters under attack

ReDoS inverts the usual economics of a flood. The attacker spends almost nothing: no botnet, no amplification, just one well-formed request aimed at a field that feeds a bad pattern. The server spends a whole core. Because the request rate is trivially low, the rate-limit and volumetric controls tuned for packets-per-second never fire, exactly the blind spot that also lets a low-and-slow attack through.

Like any application-layer attack, the request looks legitimate on every network signal, so it sails past filters that only inspect volume and reputation. A modest handful of concurrent ReDoS requests can saturate every worker thread, and on an autoscaled tier the platform reacts by adding capacity, converting an outage into a runaway bill. That is the autoscaler-exposure failure mode: the system does not fall over, it just spends without bound.

What a DDoS test measures

A test does not hunt the internet for bad regexes; it probes whether the running service has a ceiling on the cost of a single request. The measurable questions are concrete. Is there a per-request CPU or wall-clock budget that kills a runaway match. Does the regex engine enforce a backtracking or step limit. Are input sizes capped before untrusted text ever reaches a pattern. And when one request does go pathological, does one thread die cleanly or does the whole worker pool stall.

The output is a statement about the layer of first failure: the point in the stack where a few cheap requests translate into lost capacity for everyone else. A stack hardened against gigabit floods routinely fails this test, because the control that stops ReDoS is a timeout and an input cap, not a bigger pipe.

The real fix: bounded engines and input caps

The durable mitigation is not to audit every pattern by eye but to remove the exponential possibility outright. Linear-time engines such as RE2 and Rust's regex crate compile to an automaton that cannot backtrack, so match time is bounded by input length no matter how adversarial the pattern. Where the language ships a backtracking engine, a hard step or timeout limit on each match caps the blast radius even for a pattern nobody reviewed.

The cheaper layer is input hygiene: reject oversized fields before they reach a pattern, anchor expressions so they fail fast, and keep untrusted text away from quantifier soup. None of these require finding the specific vulnerable regex in advance, which is the point, because the next one gets written next sprint.

For how algorithmic-complexity vectors sit among the broader attack classes, see Understanding DDoS Attack Vectors.

ReDoS is durable knowledge in the worst way. The vulnerable patterns are written fresh in every codebase, by developers who have no reason to suspect that a validation rule is also a denial-of-service primitive. The defense is not a signature to update but a habit: bound every input, budget every request, and treat the regex engine as attack surface.