{"id":922,"date":"2026-09-07T09:28:02","date_gmt":"2026-09-07T09:28:02","guid":{"rendered":"https:\/\/www.kacateknologi.com\/en\/?p=922"},"modified":"2026-09-07T09:56:17","modified_gmt":"2026-09-07T09:56:17","slug":"redos-vulnerability","status":"publish","type":"post","link":"https:\/\/www.kacateknologi.com\/en\/redos-vulnerability\/","title":{"rendered":"$2,500 from a ReDoS Vulnerability: Take Down Any App with Evil Regex"},"content":{"rendered":"\n

KacaTeknologi.com\/en<\/strong> – ReDoS (Regular Expression Denial of Service) is an often-overlooked Denial of Service (DoS) vulnerability that can arise when applications process user-controlled regular expressions without properly limiting their complexity. A poorly designed regex can trigger excessive backtracking, causing CPU consumption to spike and the application to become extremely slow, or even hang for an extended period of time.<\/p>\n\n\n\n

In this article, we\u2019ll explore how a seemingly simple regex input can have a significant impact on an application\u2019s availability, turning a small input into a $2,500 vulnerability.<\/p>\n\n\n\n

If you’re not sure what regex is in general, I highly recommend reading this article<\/a> so you get a better understanding before reading this post.<\/em><\/p>\n\n\n\n

What is Regular Expression Denial of Service (ReDoS)?<\/h2>\n\n\n\n

Regular Expression Denial of Service (ReDoS) is a vulnerability that can make an application extremely slow by giving it a regular expression that requires an excessive amount of processing.<\/p>\n\n\n\n

To understand ReDoS, think of a regular expression as a set of rules used to check whether text follows a particular pattern. Applications use regular expressions for things like validating email addresses, checking usernames, searching text, or validating input.<\/p>\n\n\n\n

Most of the time, this process is extremely fast.<\/p>\n\n\n\n

The problem starts when a regular expression is written in a way that gives the engine too many possible ways to interpret the same input<\/strong>.<\/p>\n\n\n\n

The Evil Regex<\/h3>\n\n\n\n

One simple example is:<\/p>\n\n\n\n

^(a+)+$<\/code><\/pre>\n\n\n\n
Don’t worry if this looks confusing. The important part is what happens when the application tries to process certain inputs.<\/p>\n\n\n\n
For example, this input is easy:<\/p>\n\n\n\n
aaaaaaaaaa<\/code><\/pre>\n\n\n\n
The pattern can quickly determine that the input matches.<\/p>\n\n\n\n
Now consider an input that looks almost correct:<\/p>\n\n\n\n
aaaaaaaaaab<\/code><\/pre>\n\n\n\n
The final b<\/code> makes the input invalid.<\/p>\n\n\n\n
Instead of immediately giving up, some regex engines using a backtracking approach<\/a> start going back and trying different ways to divide the a<\/code> characters. It’s similar to trying to find your way through a maze.<\/p>\n\n\n\n
Imagine entering a maze where every few steps you have two different paths to choose from. If you reach a dead end, you go back and try another route. If there are only a few choices, this is manageable.<\/p>\n\n\n\n
But what if the maze keeps splitting into more and more paths? The number of routes you need to check can grow incredibly quickly. That’s essentially what can happen with an inefficient regular expression.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Uncontrolled Regex in Regex Input<\/h2>\n\n\n\n
In a redacted bug bounty program, I discovered an application with a Regex Export<\/strong> feature. The feature allows users to provide a regular expression, which the application then uses to find and export specific information from raw event data.<\/p>\n\n\n\n
This immediately caught my attention from a security perspective because the regex itself was controlled by the user. If the application accepted a regex with excessive backtracking potential without performing any validation or imposing complexity limits, it could potentially be abused to cause a ReDoS condition.<\/p>\n\n\n\n
Crafting the Evil Regex<\/h3>\n\n\n\n
I started with a well-known ReDoS pattern based on nested quantifiers<\/strong>, such as:<\/p>\n\n\n\n
(a+)+<\/code><\/pre>\n\n\n\n
This pattern is interesting because it gives the regex engine many different ways to divide a sequence of a<\/code> characters. If the input eventually fails to match, the engine may go back and try those different possibilities one by one.<\/p>\n\n\n\n
Since the application uses regex capture groups, I adapted the pattern to fit its expected format:<\/p>\n\n\n\n
(?<g1>(?:a+)+)(?<g2>z)<\/code><\/pre>\n\n\n\n
Here, g1<\/code> captures the sequence of a<\/code> characters, while g2<\/code> expects a z<\/code> at the end. <\/p>\n\n\n\n