CVE-2026-4867
Catastrophic Backtracking in path-to-regexp Causes DoS Risk
Publication date: 2026-03-26
Last updated on: 2026-04-16
Assigner: openjs
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| pillarjs | path-to-regexp | to 0.1.13 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1333 | The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-4867 is a Regular Expression Denial of Service (ReDoS) vulnerability in the path-to-regexp library, which is commonly used in JavaScript frameworks like Express.js and Next.js for routing.
The vulnerability occurs when a route contains three or more parameters within a single URL segment separated by characters other than a period (e.g., /:a-:b-:c). The generated regular expression allows catastrophic backtracking because the backtrack protection only covers up to two parameters.
This happens because the regex engine tries many overlapping matches due to ambiguous capture groups and lazy quantifiers, causing excessive CPU usage and slow response times when processing crafted inputs.
Routes with custom regex patterns for parameters are not affected because they override the default capture groups.
How can this vulnerability impact me? :
This vulnerability can cause a denial-of-service (DoS) condition by making the server spend excessive CPU time processing specially crafted URL paths.
Because JavaScript regex matching runs on the main thread, the excessive backtracking can block the event loop, leading to severe performance degradation and unresponsiveness.
- Latency can increase from under 1 millisecond to hundreds of milliseconds or more under attack.
- This can effectively make the affected web application unavailable to legitimate users.
The impact is availability-related, with no direct confidentiality or integrity loss.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by identifying routes in your application that contain three or more parameters within a single URL segment separated by characters other than a period (e.g., /:a-:b-:c). Such routes generate vulnerable regular expressions prone to catastrophic backtracking.
To detect exploitation attempts on your network or system, monitor for unusually long or malformed URL paths that match these vulnerable route patterns, especially those with repeated separator characters (like multiple hyphens) followed by unmatched characters, which cause excessive regex backtracking and CPU usage.
While no specific commands are provided in the resources, you can use network monitoring tools or application logs to filter requests matching suspicious URL patterns, such as those with repeated separator characters or abnormally long path segments.
Additionally, resources like the Recheck playground mentioned by the maintainer can be used to test if your routes are vulnerable by simulating crafted inputs that trigger the regex backtracking.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade the path-to-regexp library to version 0.1.13 or later, where patches prevent catastrophic backtracking by generating safer regular expressions.
If upgrading is not immediately possible, you can apply workarounds by providing custom regular expressions for parameters after the first in a single segment, ensuring these regexes do not match preceding text. For example, change routes like /:a-:b-:c to /:a-:b([^-/]+)-:c([^-/]+).
Another mitigation is to limit the URL length accepted by your application to reduce the impact of crafted long inputs that trigger excessive backtracking.
Users unable to upgrade or rewrite routes are encouraged to contact the maintainer for tailored mitigation advice, acknowledging that some fixes may break edge-case routes due to trade-offs between compatibility and security.