What is a ReDoS attack?

What is a ReDoS attack?

A ReDoS attack — short for Regular Expression Denial of Service — is a type of algorithmic complexity attack that exploits weaknesses in how regex (regular expression) engines process certain patterns. By submitting carefully crafted input, an attacker can cause a vulnerable regex engine to consume excessive CPU resources, slowing an application to a crawl or taking it offline entirely. Regular expressions are used across virtually every layer of modern software — from input validation and authentication to firewalls and log parsing. When those patterns are written inefficiently, they become a latent vulnerability waiting to be triggered. Unlike traditional denial-of-service attacks that require a flood of traffic, a ReDoS attack can sometimes succeed with a single, well-constructed request.

How does a ReDoS attack work?

At the core of every ReDoS attack is a behavior called catastrophic backtracking. To understand it, you first need to understand how most regex engines work. The majority of regex engines in production use a Nondeterministic Finite Automaton (NFA) model. When an NFA-based engine processes a pattern, it explores multiple possible matching paths through the input string. In most cases, this is fast and efficient. But certain regex patterns — particularly those involving nested quantifiers or ambiguous alternation — create a situation where the engine must explore an exponentially growing number of paths before it can confirm a match or a failure.

What makes a regex “evil”:

• Nested repetition quantifiers, such as (a+)+ or ([a-z]+)
• Alternation where one option is a subset of another, like (a|aa)+
• Patterns where a failed match forces the engine to backtrack and retry millions of combinations before giving up

When an attacker feeds one of these patterns a string specifically designed to never match — while still being close enough to require maximum exploration — the engine enters a runaway computation loop. For example, a pattern like ^(a+)+$ evaluated against a string of 30 “a” characters followed by an exclamation mark can trigger billions of backtracking steps.

Why this is particularly dangerous:

• The attack exploits legitimate application logic, not a traditional software bug
• Vulnerable patterns are often buried in third-party libraries, not first-party code
• A single malicious request can be enough to degrade or crash a service
• The root cause — an inefficient regex — may persist undetected for years
• AI-generated and LLM-suggested regex patterns have been shown to introduce ReDoS vulnerabilities, making the problem increasingly relevant in modern development pipelines

The 2019 Cloudflare outage is one of the most high-profile examples: a single poorly written regex deployed to their Web Application Firewall caused a global service disruption affecting a significant portion of internet traffic for nearly 30 minutes. The pattern consumed 100% of CPU on every server it ran on, with no volumetric attack required.

What systems and applications are vulnerable to ReDoS attacks?

ReDoS vulnerabilities are not limited to one type of system or technology. Because regular expressions are embedded throughout virtually every layer of software infrastructure, the attack surface is wide and often underappreciated.

Common vulnerability targets include:

• Web applications that use regex for input validation — email format checks, username rules, phone number formats, and password policies are all common locations for vulnerable patterns
• Web Application Firewalls (WAFs) — if the WAF itself runs on a vulnerable regex engine, an attacker can use a ReDoS payload to disable the very system meant to protect the application behind it
• Authentication and identity systems — login forms, token validation, and session management routines frequently rely on regex, and a vulnerable pattern here
  can block legitimate users from accessing systems entirely
• Databases — many databases support regex-based queries, and a crafted input can cause query-level denial of service affecting the entire data tier
• Email filtering and security scanning tools — these systems process large volumes of untrusted content and often rely heavily on pattern matching
• Open source libraries and dependencies — research has found that more than 10% of popular open source repositories contain regex patterns vulnerable to ReDoS; because these libraries are widely shared, a single vulnerable dependency can expose thousands of downstream applications simultaneously

Factors that amplify risk:

• Applications that accept user-supplied input and pass it directly into regex evaluation — including cases where users can influence the pattern itself, not just the input string
• Multi-tenant environments where one user’s malicious request can degrade service for all others
• Single-threaded or event-loop architectures (such as Node.js) where a blocked regex evaluation stalls the entire processing pipeline
• Systems with no input length restrictions or regex execution timeouts, allowing an attacker’s payload to run indefinitely

The challenge for security and development teams is that vulnerable patterns are rarely obvious at code review time. A pattern that looks reasonable in isolation may behave catastrophically on specific inputs. And because the vulnerability lives in the application logic itself — not in a missing patch or misconfigured service — standard vulnerability scanners often miss it entirely.

How can organizations prevent ReDoS attacks?

Preventing ReDoS requires a combination of secure coding practices, developer tooling, and runtime safeguards. No single control eliminates the risk entirely, but layered defenses significantly reduce both the likelihood and impact of an attack.

At the code level:

• Audit all regex patterns for nested quantifiers, ambiguous alternation, and other constructs known to trigger catastrophic backtracking
• Use atomic grouping or possessive quantifiers where the regex engine supports them— these eliminate backtracking on specific subexpressions
• Avoid allowing user-supplied input to influence regex patterns directly; if dynamic patterns are unavoidable, validate and sandbox them strictly
• Replace backtracking-based regex engines with linear-time alternatives such as Google’s RE2 library, which is designed to be immune to ReDoS by construction

At the input and runtime level:

• Enforce strict maximum input length limits before any regex evaluation occurs — shorter inputs mean fewer backtracking paths
• Implement execution timeouts on regex operations so that a runaway evaluation is interrupted rather than allowed to exhaust system resources
• Apply rate limiting and throttling to any endpoint that performs regex-based validation

In the development lifecycle:

• Integrate static analysis tools that can identify vulnerable regex patterns during development, before code reaches production
• Include ReDoS scenarios in penetration testing and application security testing programs
• Establish policies for vetting third-party libraries and dependencies for known regex vulnerabilities before adoption
• Monitor CPU usage for unexpected spikes that may indicate a ReDoS event in progress — establish baseline alerting so anomalies are caught quickly

ReDoS attacks are easy to overlook precisely because they exploit normal application functionality rather than traditional exploits. A single vulnerable regex pattern— in your own code or a dependency — can be enough to take a service offline. Organizations that treat regex hygiene as part of their secure development lifecycle, and back it up with runtime controls and monitoring, are best positioned to prevent and detect these attacks before they cause lasting damage.