Description
The current regress regex engine appears to allow unbounded backtracking, which can lead to catastrophic backtracking (ReDoS) for certain valid patterns.
When used by JavaScript engines such as Boa, pathological patterns with nested quantifiers can cause extremely long execution times or effectively hang the engine because there is no backtracking or execution limit exposed by the API.
Example
var re = new RegExp("(a+)+$");
re.test("a".repeat(25) + "!");Increasing the input length causes exponential execution time due to backtracking.
Expected behavior
The regex engine should provide a mechanism to bound execution, such as:
- a configurable backtracking limit
- a step counter / instruction budget
- an interrupt / timeout hook
This would allow embedding runtimes (e.g., Boa) to prevent regex-based denial-of-service attacks.
Additional context
This is a well-known issue class (ReDoS / CWE-1333).
Providing an execution limit or interruption mechanism in regress would allow upstream projects to guard against pathological regex patterns.
Description
The current regress regex engine appears to allow unbounded backtracking, which can lead to catastrophic backtracking (ReDoS) for certain valid patterns.
When used by JavaScript engines such as Boa, pathological patterns with nested quantifiers can cause extremely long execution times or effectively hang the engine because there is no backtracking or execution limit exposed by the API.
Example
Increasing the input length causes exponential execution time due to backtracking.
Expected behavior
The regex engine should provide a mechanism to bound execution, such as:
This would allow embedding runtimes (e.g., Boa) to prevent regex-based denial-of-service attacks.
Additional context
This is a well-known issue class (ReDoS / CWE-1333).
Providing an execution limit or interruption mechanism in regress would allow upstream projects to guard against pathological regex patterns.