Cybersecurity glossary
What is Regular Expression Denial of Service (ReDoS)?
Learn what Regular Expression Denial of Service (ReDoS) is, how evil regex backtracking burns CPU on crafted input, where it shows up in validation, and how to write safe patterns and engines.
Definition
Regular Expression Denial of Service (ReDoS) is an availability attack in which a vulnerable regular expression—typically with nested quantifiers that cause catastrophic backtracking—takes extreme CPU time on carefully crafted input, stalling the process that evaluates it.
Why ReDoS matters
Developers treat regex as “just validation.” Regular Expression Denial of Service (ReDoS) shows that some patterns turn matching into a combinatorial search. Crafted inputs force catastrophic backtracking and burn CPU until workers stop answering real traffic.
Unlike volumetric DDoS, ReDoS often needs little bandwidth—just a vulnerable pattern and a string that explores its worst path. That makes it a classic application-layer resource exhaustion bug.
How ReDoS works
Find a backtracking regex
Locate patterns with nested or overlapping quantifiers used on request fields, logs, or routes.
Craft near-miss input
Build strings that almost match, forcing the engine to try enormous numbers of partitions.
Submit through hot paths
Hit login validation, search, webhooks, or middleware that runs the regex on every request.
Trigger catastrophic backtracking
CPU time grows exponentially (or worse) with input length for vulnerable constructions.
Starve the runtime
Event loops and worker pools block; latency spikes and timeouts cascade.
Deny availability
Legitimate users fail while a few evil strings monopolize compute.
Where evil regex shows up
Input validators
Overly clever email, URL, and password-complexity patterns with nested `+`/`*` groups.
Parsers and WAFs
Signature rules that match untrusted bodies with ambiguous repetition.
User-built filters
Features that compile caller-supplied patterns without timeouts or RE2-style engines.
Hot middleware
Per-request sanitizers that run on every connection amplify one slow match globally.
Prevention
| Practice | Detail |
|---|---|
| Simplify patterns | Remove nested quantifiers on overlapping tokens; prefer explicit character classes and bounded repeats. |
| Use linear engines | Prefer RE2-like engines that reject or avoid backtracking blow-ups for untrusted input. |
| Timeout matches | Hard-cap regex evaluation time and fail closed when the budget is exceeded. |
| Never trust patterns | Do not compile raw user regexes; allowlist fields and use safer query mechanisms. |
- Audit validators and middleware for nested quantifiers and ambiguous alternation.
- Add unit tests with long near-miss strings and assert completion within a tight budget.
- Enable regex timeouts where the platform supports them (for example .NET match timeouts).
- Move hot-path checks to parsers or allowlists instead of complex regex.
- Isolate optional heavy matching off the main request thread when unavoidable.
- Scan dependencies for known ReDoS-prone patterns in popular libraries.
- Treat missing match timeouts as [security misconfiguration](/glossary/security-misconfiguration).
- Document ReDoS as CPU DoS distinct from compression bombs and network floods.
The practical takeaway
ReDoS is availability loss from evil regex backtracking—not bandwidth floods or archive inflation. Fix the pattern, bound match time, or switch to a linear-time engine.
If a regex runs on untrusted strings in a hot path, assume attackers will hunt its worst-case input.
Related security terms
Denial of Service (DoS)
The broader availability-attack category that ReDoS instantiates at the regex engine.
Resource Exhaustion
CPU-focused exhaustion when backtracking monopolizes worker threads.
Unrestricted Resource Consumption
API-oriented framing for missing limits on expensive operations, including regex.
Security Misconfiguration
Shipping debug validators or unbounded regex timeouts is a common misconfiguration.
Frequently asked questions
What is ReDoS in simple terms?
A bad regex can get stuck trying millions of matching paths. An attacker sends a short string that makes your server’s CPU spin for seconds or minutes per request.
What is catastrophic backtracking?
When a backtracking engine explores an exponential number of ways to match overlapping quantifiers (for example nested `.*` / `(a+)+` style patterns) against non-matching or near-matching input.
Which languages are affected?
Any backtracking engine can be vulnerable—JavaScript, Python `re`, Java, Ruby, .NET, and many others—unless you use a linear-time engine or hard timeouts.
Is ReDoS the same as a zip bomb?
No. Zip bombs amplify disk/memory via decompression. ReDoS amplifies CPU via regex evaluation on ordinary strings.
Where do vulnerable regexes appear?
Email/URL validators, log parsers, WAFs, input sanitizers, route matchers, and user-supplied search filters compiled into regex.
How do you prevent ReDoS?
Avoid nested quantifiers on overlapping groups, prefer possessive/atomic constructs or non-backtracking engines, set match timeouts, and never compile untrusted patterns.
Can a few requests take down a server?
Yes. ReDoS is often a low-bandwidth application-layer DoS: one slow match can block an event-loop thread or a worker.
References
Explore authoritative guidance and frameworks related to regular expression denial of service (redos).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.