What Is Regular Expression Denial of Service (ReDoS)?

Regular expressions, often called regex, help applications recognize patterns in text, with developers using them to validate email addresses, check form entries, and process user input. When a regular expression is poorly designed, certain inputs can cause it to consume far more processing power than expected.

Attackers can exploit this weakness to create a denial-of-service (DoS) condition. Unlike attacks that overwhelm a server with large amounts of traffic, ReDoS can disrupt an application by forcing it to perform unusually expensive calculations.

A successful ReDoS attack can lead to:

• Excessive CPU consumption: Vulnerable regex operations use significant processing resources, potentially affecting other application tasks.
• Slow application performance: Requests take longer to process, creating delays for legitimate users.
• Service unavailability: Exhausted processing capacity can cause requests to fail, time out, or become temporarily unavailable.
• Operational disruption: Teams may need to investigate affected services, restore availability, and correct the underlying vulnerability.

ReDoS is particularly relevant to applications that process untrusted input. Understanding the broader category of denial-of-service attacks helps explain how attackers target availability through different techniques.

How a ReDoS attack works

A ReDoS attack occurs when a vulnerable regular expression processes input that triggers excessive matching operations. The problem typically involves how a regex engine evaluates competing possibilities while attempting to find a match.

What is catastrophic backtracking?

Many regex engines use backtracking to evaluate text patterns. When an attempted match fails, the engine can return to an earlier point and try another possible interpretation. This behavior is normally efficient, however certain patterns contain overlapping or nested repetitions that allow the same input to be evaluated in many different ways.

Catastrophic backtracking occurs when the number of matching attempts grows dramatically as the input changes or increases in length. In vulnerable implementations, a relatively short string can require an excessive amount of processing time.

The ReDoS attack sequence

A typical ReDoS attack follows five stages:

1. A vulnerable regex exists. An application uses a pattern that can require excessive processing for certain inputs.
2. An attacker submits crafted input. The input is designed to trigger inefficient matching behavior.
3. The regex engine repeatedly evaluates possibilities. The engine explores alternative matches, potentially performing enormous amounts of work.
4. Processing resources become strained. CPU usage increases, and application threads or workers may remain occupied.
5. Application availability suffers. Legitimate requests can slow down, time out, or fail.

Not every regex engine uses backtracking, and the resulting performance impact depends on the pattern, input, engine implementation, and application environment.

Common causes and examples of ReDoS

ReDoS vulnerabilities often result from a combination of inefficient regex patterns, vulnerable matching behavior, and attacker-controlled input. The risk increases when applications evaluate these patterns without appropriate safeguards.

Regex patterns that can cause problems

Several characteristics can contribute to expensive matching operations:

• Nested quantifiers: Repetition operators inside other repeating groups can create numerous possible matching combinations.
• Overlapping alternatives: Different branches of a regex may match the same characters, forcing the engine to explore multiple paths.
• Ambiguous matching rules: Patterns that permit many interpretations of the same string can increase processing time.
• Unrestricted input: Applications that accept large or specially constructed strings may expose vulnerable patterns to exploitation.

For example, the regex “(a+)+$” contains nested repetition. In some backtracking engines, a string containing many “a” characters followed by a character that prevents a complete match can trigger excessive backtracking.

The issue isn’t simply that the input is long, but that the combination of the pattern's structure and the engine's matching behavior creates the vulnerability.

Where ReDoS vulnerabilities appear

Form validation

An application uses a complex regex to validate user-submitted information. A specially constructed input causes the validation process to consume excessive CPU time, potentially delaying other requests.

Web request processing

A web application evaluates URL paths, headers, or other request data against vulnerable patterns. An attacker repeatedly submits inputs that trigger expensive evaluations, affecting response times.

Third-party software dependencies

An application relies on an external package that contains a vulnerable regular expression. Even when developers haven’t written the regex themselves, processing untrusted input through that dependency may introduce risk.

These scenarios illustrate why ReDoS belongs within the broader category of web application vulnerabilities, where the vulnerable behavior may exist in application code, supporting libraries, or dependencies.

How to prevent ReDoS attacks

Preventing ReDoS requires addressing inefficient regex patterns and limiting opportunities for resource exhaustion. Development and security teams should consider both the underlying vulnerability and the safeguards surrounding regex execution.

Use safer regular expression patterns

Review patterns for nested repetitions, overlapping alternatives, and unnecessary complexity. Simplifying ambiguous expressions can reduce the number of matching paths an engine must evaluate.

Where appropriate, developers can use regex engines designed to provide predictable, linear-time matching for supported syntax. Engine choice matters because different implementations handle complex patterns differently.

Apply input and execution safeguards

Additional controls can help limit the impact of expensive matching operations:

• Restrict input length: Set reasonable limits based on the expected data rather than allowing unrestricted strings.
• Enforce execution timeouts: Use supported timeout mechanisms to prevent individual regex evaluations from running indefinitely.
• Isolate expensive operations: Where practical, separate resource-intensive processing so it can’t monopolize shared application resources.
• Maintain dependencies: Update affected libraries and review security advisories for known regex-related vulnerabilities.

Test and remediate vulnerable code

Security testing should include regex patterns that process untrusted input, especially those used in authentication, validation, and request handling.

Teams can combine code review, dependency analysis, and controlled performance testing to identify potentially vulnerable expressions. Web application security testing can provide a broader framework for discovering weaknesses in application behavior.

Once a vulnerable expression is identified, remediation may involve rewriting the pattern, changing its matching engine, replacing an affected dependency, or introducing appropriate execution constraints.

How ReDoS fits into security operations

Application security and vulnerability management

Application security teams help identify unsafe coding patterns and evaluate how applications handle untrusted input. Developers can incorporate regex performance checks into secure coding practices and review third-party dependencies for known issues.

Organizations developing broader application security programs can incorporate these activities alongside code review, testing, and remediation workflows.

Vulnerability management teams help assess affected assets, understand the potential impact on availability, and prioritize fixes. A broader vulnerability management approach can support tracking remediation across applications and dependencies.

Testing and incident response

Dynamic application security testing (DAST) can help identify certain weaknesses in running applications, although conventional scans may not reliably detect every ReDoS vulnerability. Targeted testing and code-level analysis may be necessary.

Authorized penetration testing can also help assess application security weaknesses, provided tests account for the risk of disrupting production services. If an application experiences suspected ReDoS activity, security teams can investigate unusual CPU consumption, slow requests, repeated input patterns, and application errors.

The goal is to determine whether expensive regex evaluation contributed to the disruption, and then address the vulnerable code while restoring normal service.