CVE-2026-4867: path-to-regexp vulnerable to Regular Expression Denial of Service via multiple route parameters
Impact
A bad regular expression is generated any time you have three or more parameters within a single segment, separated by something that is not a period (.). For example, /:a-:b-:c or /:a-:b-:c-:d. The backtrack protection added in path-to-regexp@0.1.12 only prevents ambiguity for two parameters. With three or more, the generated lookahead does not block single separator characters, so capture groups overlap and cause catastrophic backtracking.
Patches
Upgrade to path-to-regexp@0.1.13
Custom regex patterns in route definitions (e.g., /:a-:b([^-/]+)-:c([^-/]+)) are not affected because they override the default capture group.
Workarounds
All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change /:a-:b-:c to /:a-:b([^-/]+)-:c([^-/]+).
If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length.
References
- GHSA-9wv6-86v2-598j - Detailed blog post: ReDoS the web
Other sources
Impact:
A bad regular expression is generated any time you have three or more parameters within a single segment, separated by something that is not a period (.). For example, /:a-:b-:c or /:a-:b-:c-:d. The backtrack protection added in path-to-regexp@0.1.12 only prevents ambiguity for two parameters. With three or more, the generated lookahead does not block single separator characters, so capture groups overlap and cause catastrophic backtracking.
Patches:
Upgrade to path-to-regexp@0.1.13
Custom regex patterns in route definitions (e.g., /:a-:b([^-/]+)-:c([^-/]+)) are not affected because they override the default capture group.
Workarounds:
All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change /:a-:b-:c to /:a-:b([^-/]+)-:c([^-/]+).
If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/path-to-regexpto a version that resolves this vulnerability.Fixed in 0.1.13 - Upgrade
Upgrade
path-to-regexpto a version that resolves this vulnerability.Fixed in 0.1.13 - Configuration
For routes that have three or more parameters in a single segment separated by something other than a period (.), rewrite the route pattern so that parameters after the first use custom capture regexes that override the default capture group (e.g., change '/:a-:b-:c' to '/:a-:b([^-/]+)-:c([^-/]+)'). Ensure the custom regex does not match the text before the parameter.
path-to-regexp route definitions parameter capture regex = Use custom regex for parameters after the first (e.g., change /:a-:b-:c to /:a-:b([^-/]+)-:c([^-/]+)) - Compensating control
If paths cannot be rewritten and the vulnerable version cannot be upgraded, limit the URL length.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-4867?
CVE-2026-4867 has a medium severity level due to its potential for causing Regular Expression Denial of Service.
How do I fix CVE-2026-4867?
To fix CVE-2026-4867, update the path-to-regexp package to version 0.1.13 or later.
What causes CVE-2026-4867?
CVE-2026-4867 is caused by the generation of a bad regular expression when using three or more parameters in a single segment.
Which versions are affected by CVE-2026-4867?
Versions of path-to-regexp up to and including 0.1.12 are affected by CVE-2026-4867.
What is Regular Expression Denial of Service in CVE-2026-4867?
Regular Expression Denial of Service in CVE-2026-4867 occurs when complex regular expressions lead to excessive computation time, potentially slowing down or crashing applications.