What Are ReDoS Attacks? How Regular Expressions Can Take Down Your Application

What Are ReDoS Attacks?

If you have a problem, and you solve it with RegEx, you now have two problems. Although a comical statement, the truth may actually be that you have three problems. The third being the dreaded ReDoS attack. While a common security attack vector for applications ReDoS, unlike flashy zero-days or Hollywood-style hacks, works by being boringly patient.

ReDoS attacks are subtle, sneaky, and surprisingly common. Let’s unpack what ReDoS attacks are, how they work, why they’re dangerous, and—most importantly—how to avoid accidentally inviting one into your production systems.

‍

ReDoS, in Plain English

ReDoS stands for Regular Expression Denial of Service.

At a high level, a ReDoS attack happens when:

• An application uses a vulnerable regular expression
• An attacker supplies carefully crafted input
• The regex engine takes an absurdly long time to evaluate that input
• CPU usage spikes
• Your application becomes slow or completely unavailable

No data is stolen. No systems are “broken into.” Your app just… grinds to a halt.

It’s denial of service by math.

‍

Why Regular Expressions Are the Perfect Trap

Regular expressions are powerful, expressive, and deceptively easy to misuse. Hence the “two problems” statement.

Many popular regex engines (including those in JavaScript, Java, Python, Ruby, and others) use backtracking algorithms. Backtracking allows regex engines to be flexible, but it comes with a dangerous downside: in certain patterns, the engine can end up trying every possible way to match an input.

That can mean:

• Linear input size
• Exponential processing time

A small input can trigger a massive amount of computation.

This is the heart of ReDoS.

‍

A Tiny Example With Big Consequences

Consider this innocent-looking regex:

^(a+)+$

‍

At first glance, it seems reasonable: “match one or more groups of one or more a’s.”

Now give it this input:

aaaaaaaaaaaaaaaaX

‍

Here’s what happens:

1. The engine tries to match all the as
2. It hits the X and fails
3. It backtracks and tries a different way to group the as
4. Fails again
5. Tries another grouping
6. And another
7. And another…
   
   

The number of possibilities explodes.

Your CPU fans spin up.
Your response time spikes.
Your service goes down.

All from a string of as and one annoying X.

‍

What Makes a Regex Vulnerable?

Not all regular expressions are dangerous. ReDoS vulnerabilities tend to appear when certain features are combined in risky ways.

Nested quantifiers

(a+)+

(.*)+

(.+)*

‍

Ambiguous alternation

(a|aa)+

‍

Unbounded repetition over broad patterns

(.*)

(.+)

‍

Anchors missing when they should exist

.*foo.*

‍

These patterns force the regex engine to guess—and guessing is expensive.

‍

Why Attackers Love ReDoS

ReDoS attacks are appealing because they’re:

• Cheap – no botnet required
• Hard to detect – traffic looks normal
• Low risk – no intrusion, no malware
• Effective – even a single request can stall a server

An attacker doesn’t need bandwidth. They need one request that takes 30 seconds to process.

Multiply that by a few concurrent requests, and you’re done.

‍

Where ReDoS Shows Up in Real Applications

ReDoS vulnerabilities often hide in places developers don’t think of as “security-critical.”

Common locations include:

• Input validation (emails, usernames, phone numbers)
• URL routing
• Log parsing
• Search filters
• API request validation
• Form field sanitization

Ironically, many ReDoS bugs live in security code—the regex was added to protect the app.

‍

Why This Is Still a Problem in 2025

You might expect this to be a solved problem by now. It isn’t.

Reasons include:

• Regexes are generated with vibe coding without scrutiny
• Libraries ship vulnerable patterns
• Performance testing rarely includes pathological inputs
• Regex engines prioritize compatibility over safety
• Developers assume “small input = small cost” (not true)

Even modern frameworks still rely on backtracking engines by default.

‍

How to Defend Against ReDoS

The good news: ReDoS is very preventable once you know what to look for.

‍

1. Avoid Catastrophic Patterns

Rewrite risky regexes to be more explicit.

Bad

^(.*)+$

‍

Better

^[^]*$

‍

Or better yet: don’t use regex at all if you don’t need it.

‍

2. Anchor Aggressively

Anchors (^ and $) limit the engine’s search space.

Bad

.*admin.*

‍

Better

^.*admin.*$

‍

Even better: don’t use .* unless absolutely necessary.

‍

3. Limit Input Length

If user input is capped at 255 characters, catastrophic backtracking becomes far less dangerous.

This is a simple, high-impact mitigation.

‍

4. Prefer Non-Backtracking Engines When Available

Some regex engines are immune to ReDoS by design:

• RE2 (used by Google)
• Rust’s regex crate
• .NET’s newer timeout-enabled regex APIs

If your platform supports timeouts or safe engines—use them.

‍

5. Add Regex Timeouts

Some languages allow execution time limits.

Examples:

• Java’s Pattern with timeouts (via wrappers)
• .NET Regex timeout parameter

A timeout turns a potential outage into a controlled failure.

‍

6. Test for ReDoS Explicitly

Security testing shouldn’t just look for SQL injection and XSS.

Include:

• Fuzzing with long repetitive input
• Known “evil regex” test cases
• Static analysis tools that flag risky patterns

If you rely on third-party libraries, scan them too.

‍

ReDoS vs Other Denial-of-Service Attacks

‍

‍

ReDoS is the quiet one in the corner, breaking your app while everyone looks elsewhere.

‍

The Takeaway

ReDoS attacks aren’t flashy.
They aren’t new.
And they aren’t going away.

‍

They exist at the intersection of:

• Developer convenience
• Regex engine behavior
• Assumptions about performance

‍

The scariest part? Many applications are vulnerable right now and don’t know it.

If your app:

• Accepts user input
• Uses regular expressions
• Runs on a backtracking regex engine

‍

Then ReDoS is not hypothetical—it’s a risk.

Treat regexes like code, not strings.
Review them.
Test them.
And when in doubt, make them boring.

Boring regexes don’t melt servers—and that’s a win.

‍