Regex DoS is a denial-of-service attack that exploits inefficient regular expressions to consume excessive CPU and slow or crash a system. In security tooling, especially input validation, log processing, and API filters, carefully crafted text can trigger catastrophic backtracking or similar worst-case behavior, creating an availability risk.
How Regex DoS Works
Regex DoS happens when a regular expression is written or used in a way that can take far longer to evaluate on certain inputs than on normal ones. The dangerous pattern is not the regex feature itself, but an input path where a crafted string triggers excessive backtracking, repeated retries, or other worst-case matching behavior.
This matters because regexes often sit inside security-sensitive paths such as validation, filtering, parsing, and rule engines. When a single request can force disproportionate CPU work, the result is an availability problem that scales poorly under load and can degrade an entire service even when the attacker sends relatively little traffic.
Where Regex DoS Shows Up
Regex DoS most often appears where patterns are applied automatically to untrusted or semi-trusted text. Common examples include web request validation, API gateways, content filters, log processors, SIEM parsing rules, and security tooling that repeatedly evaluates the same expression across many events.
The risk is higher when the regex is complex, nested, or written with ambiguous repetition. In those cases, the engine may explore many possible match paths before concluding that the input does not match, or before settling on the correct match. That behavior can be hard to notice in normal testing because the issue often appears only with specific edge-case inputs.
Why It Is Dangerous in Security Tooling
Security controls often process attacker-controlled data at high volume, which makes them especially sensitive to inefficient matching. A slow regex in an input filter or log pipeline can create backlogs, delay alerting, and consume CPU that other defensive components need to function.
That makes Regex DoS more than a performance nuisance. In a protection layer, latency and exhaustion can become a control failure, because the system may stop validating inputs quickly enough, miss events, or fall behind during peak traffic or during an attack that deliberately targets the expensive pattern.
Detecting and Preventing Regex DoS
Prevention starts with reviewing which regular expressions are evaluated on untrusted input and how often they run. Patterns that use nested quantifiers, overlapping alternation, or ambiguous repetition deserve special scrutiny, especially in code paths that face public traffic or process large event streams.
Well-designed regexes reduce ambiguity, but operational safeguards also matter. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control baseline for limiting system exhaustion, validating inputs, and monitoring abnormal resource use. OWASP API Security Top 10 is also relevant when regex-heavy filters or gateways can be driven into expensive processing by crafted requests.
Risk and Threat Considerations
Regex DoS is dangerous because the attacker does not need to break the regex to abuse it. They only need an input that forces expensive matching, which can turn a small number of requests into a disproportionate CPU drain and create a practical availability attack.
Failure mechanism: The regex engine explores many possible match paths, then repeats that work across requests, threads, or log events until the service becomes slow or unresponsive.
Impact: Validation, filtering, and log-processing systems can stall, backlog, or fail open under pressure, reducing availability and weakening dependent security controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-13 — Predictable Failure Prevention | Regex DoS exploits avoidable worst-case processing in security-relevant controls |
| SI-4 — System Monitoring | Detection of regex-driven resource exhaustion depends on monitoring abnormal CPU and latency | |
| Recommendation — Review regex paths for worst-case behavior and prevent control exhaustion from pathological inputs. Alert on CPU spikes, queue growth, and latency that indicate regex evaluation abuse. | ||
| OWASP ASVS | V13 — Configuration | Regex-heavy validation and filtering belong in secure configuration and review of security-relevant inputs |
| Recommendation — Tighten validation rules and inspect regex patterns for complexity and ambiguity before deployment. | ||
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | Regex DoS is a resource exhaustion pattern often triggered through API-facing input paths |
| Recommendation — Constrain expensive request processing and bound regex-based checks on public endpoints. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Regex safety is part of secure application logic that protects availability |
| Recommendation — Test application regexes for catastrophic backtracking before they reach production. | ||
Practitioner Guidance
What to watch for: Treat any regex that processes untrusted input as a performance-sensitive control, not just a correctness check. The safest review question is whether a pattern can be forced into worst-case behavior by malformed or adversarial text.
Common misunderstanding: “It passed functional tests” does not mean it is safe. Regex DoS usually appears only with pathological inputs, so teams need explicit attention to complexity and runtime behavior, especially in security tooling and API-facing paths.