CVE-2024-45296 – path-to-regexp

Package

Manager: npm
Name: path-to-regexp
Vulnerable Version: >=0.2.0 <1.9.0 || >=0 <0.1.10 || >=7.0.0 <8.0.0 || >=2.0.0 <3.3.0 || >=4.0.0 <6.3.0

Severity

Level: High

CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVSS v4.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

EPSS: 0.00167 pctl0.38331

Details

path-to-regexp outputs backtracking regular expressions ### Impact A bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (`.`). For example, `/:a-:b`. ### Patches For users of 0.1, upgrade to `0.1.10`. All other users should upgrade to `8.0.0`. These versions add backtrack protection when a custom regex pattern is not provided: - [0.1.10](https://github.com/pillarjs/path-to-regexp/releases/tag/v0.1.10) - [1.9.0](https://github.com/pillarjs/path-to-regexp/releases/tag/v1.9.0) - [3.3.0](https://github.com/pillarjs/path-to-regexp/releases/tag/v3.3.0) - [6.3.0](https://github.com/pillarjs/path-to-regexp/releases/tag/v6.3.0) They do not protect against vulnerable user supplied capture groups. Protecting against explicit user patterns is out of scope for old versions and not considered a vulnerability. Version [7.1.0](https://github.com/pillarjs/path-to-regexp/releases/tag/v7.1.0) can enable `strict: true` and get an error when the regular expression might be bad. Version [8.0.0](https://github.com/pillarjs/path-to-regexp/releases/tag/v8.0.0) removes the features that can cause a ReDoS. ### 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` to `/:a-:b([^-/]+)`. If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length. For example, halving the attack string improves performance by 4x faster. ### Details Using `/:a-:b` will produce the regular expression `/^\/([^\/]+?)-([^\/]+?)\/?$/`. This can be exploited by a path such as `/a${'-a'.repeat(8_000)}/a`. [OWASP](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) has a good example of why this occurs, but the TL;DR is the `/a` at the end ensures this route would never match but due to naive backtracking it will still attempt every combination of the `:a-:b` on the repeated 8,000 `-a`. Because JavaScript is single threaded and regex matching runs on the main thread, poor performance will block the event loop and can lead to a DoS. In local benchmarks, exploiting the unsafe regex will result in performance that is over 1000x worse than the safe regex. In a more realistic environment using Express v4 and 10 concurrent connections, this translated to average latency of ~600ms vs 1ms. ### References * [OWASP](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) * [Detailed blog post](https://blakeembrey.com/posts/2024-09-web-redos/)

Metadata

Created: 2024-09-09T20:19:15Z
Modified: 2025-01-24T21:31:27Z
Source: https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2024/09/GHSA-9wv6-86v2-598j/GHSA-9wv6-86v2-598j.json
CWE IDs: ["CWE-1333"]
Alternative ID: GHSA-9wv6-86v2-598j
Finding: F211
Auto approve: 1