GHSA-37ch-88jc-xwx2 CVE-2024-45296 CVE-2026-4867 GHSA-9wv6-86v2-598j
path-to-regexp vulnerable to Regular Expression Denial of Service via multiple route parameters
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.93%
- Chance of exploitation in the next 30 days. Higher than 60.70% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-1333 Inefficient Regular Expression Complexity
- Fix
0.1.13- Upgrade path-to-regexp to this version or later
Description
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
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| path-to-regexp | < 0.1.13 |
0.1.13 |
| path-to-regexp | < 0.1.13 |
0.1.13 |
| path-to-regexp | >= 0.2.0, < 1.9.0 |
1.9.0 |
| path-to-regexp | < 0.1.10 |
0.1.10 |
| path-to-regexp | >= 7.0.0, < 8.0.0 |
8.0.0 |
| path-to-regexp | >= 2.0.0, < 3.3.0 |
3.3.0 |
| path-to-regexp | >= 4.0.0, < 6.3.0 |
6.3.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
path-to-regexp npm → 0.1.13
- npm
npm install path-to-regexp@0.1.13- yarn
yarn add path-to-regexp@0.1.13- pnpm
pnpm add path-to-regexp@0.1.13
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- High
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
- Exploit maturity
- Proof of concept
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Weakness
CWE-1333: Inefficient Regular Expression Complexity
The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.
How to prevent it
- Architecture and Design: Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
- System Configuration: Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
- Implementation: Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
- Implementation: Limit the length of the input that the regular expression will process.
References
Advisories
Packages
Other links
- blakeembrey.com/posts/2024-09-web-redos
- cna.openjsf.org/security-advisories.html
- github.com/pillarjs/path-to-regexp/releases/tag/v.0.1.13
- github.com/pillarjs/path-to-regexp/security/advisories/GHSA-9wv6-86v2-598j
- github.com/pillarjs/path-to-regexp/commit/29b96b4a1de52824e1ca0f49a701183cc4ed476f
- github.com/pillarjs/path-to-regexp/commit/60f2121e9b66b7b622cc01080df0aabda9eedee6
- github.com/pillarjs/path-to-regexp/commit/925ac8e3c5780b02f58cbd4e52f95da8ad2ac485
- github.com/pillarjs/path-to-regexp/commit/d31670ae8f6e69cbfd56e835742195b7d10942ef
- github.com/pillarjs/path-to-regexp/commit/f1253b47b347dcb909e3e80b0eb2649109e59894
- github.com/pillarjs/path-to-regexp/releases/tag/v6.3.0
- security.netapp.com/advisory/ntap-20250124-0001
- security.netapp.com/advisory/ntap-20250124-0001
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-j3q9-mxjg-w52f path-to-regexp vulnerable to Denial of Service via sequential optional groups | High | Also affects path-to-regexp |
| GHSA-27v5-c462-wpq7 path-to-regexp vulnerable to Regular Expression Denial of Service via multiple wildcards | Medium | Also affects path-to-regexp |
| GHSA-rhx6-c78j-4q9w path-to-regexp contains a ReDoS | High | Also affects path-to-regexp |
| GHSA-7wch-p9px-956x Forge: Regular expression denial of service in PEM decoding (pem.decode) | High | Same weakness, CWE-1333 |
| GHSA-xcq7-p3pf-p88h OpenTelemetry Python: Unbounded tracestate parsing in opentelemetry-api | Medium | Same weakness, CWE-1333 |
| GHSA-xgh8-jp6q-p5x8 Pillow: ReDoS in XbmImagePlugin: 512-byte file stalls Image.open() for minutes | High | Same weakness, CWE-1333 |
| GHSA-rxp7-6hxx-x8q5 ip-address: Address6 matches a zone identifier in quadratic time ahead of its length limit, allowing a single long string to stall the process | Medium | Same weakness, CWE-1333 |
| GHSA-r925-mgvr-h9cc Symfony: ReDoS in HeaderUtils::split() Reachable Through the Cache-Control Request Header | High | Same weakness, CWE-1333 |
Credits: EthanKim88, UlisesGascon, blakeembrey
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor