VulnerableCode Package Details - pkg:deb/debian/node-path-to-regexp@6.3.0-1?distro=trixie

Search for packages

Vulnerability	Summary	Fixed by
VCID-1vjw-mm86-k7gn Aliases: CVE-2026-4926 GHSA-j3q9-mxjg-w52f	path-to-regexp vulnerable to Denial of Service via sequential optional groups ### Impact A bad regular expression is generated any time you have multiple sequential optional groups (curly brace syntax), such as `{a}{b}{c}:z`. The generated regex grows exponentially with the number of groups, causing denial of service. ### Patches Fixed in version 8.4.0. ### Workarounds Limit the number of sequential optional groups in route patterns. Avoid passing user-controlled input as route patterns.	8.4.0-1 Affected by 0 other vulnerabilities. 8.4.1-1 Affected by 0 other vulnerabilities.
VCID-366w-k4rs-v7d3 Aliases: CVE-2026-4923 GHSA-27v5-c462-wpq7	path-to-regexp vulnerable to Regular Expression Denial of Service via multiple wildcards ### Impact When using multiple wildcards, combined with at least one parameter, a regular expression can be generated that is vulnerable to ReDoS. This backtracking vulnerability requires the second wildcard to be somewhere other than the end of the path. Unsafe examples: ``` /foo-bar-:baz /a-:b-c-:d /x/a-:b/c/y ``` Safe examples: ``` /foo-:bar /foo-:bar-*baz ``` ### Patches Upgrade to version `8.4.0`. ### Workarounds If developers are using multiple wildcard parameters, they can check the regex output with a tool such as https://makenowjust-labs.github.io/recheck/playground/ to confirm whether a path is vulnerable.	8.4.0-1 Affected by 0 other vulnerabilities. 8.4.1-1 Affected by 0 other vulnerabilities.

Vulnerability

Summary

Fixed by

VCID-1vjw-mm86-k7gn
Aliases:
CVE-2026-4926
GHSA-j3q9-mxjg-w52f

path-to-regexp vulnerable to Denial of Service via sequential optional groups ### Impact A bad regular expression is generated any time you have multiple sequential optional groups (curly brace syntax), such as `{a}{b}{c}:z`. The generated regex grows exponentially with the number of groups, causing denial of service. ### Patches Fixed in version 8.4.0. ### Workarounds Limit the number of sequential optional groups in route patterns. Avoid passing user-controlled input as route patterns.

8.4.0-1
Affected by 0 other vulnerabilities.

8.4.1-1
Affected by 0 other vulnerabilities.

VCID-366w-k4rs-v7d3
Aliases:
CVE-2026-4923
GHSA-27v5-c462-wpq7

path-to-regexp vulnerable to Regular Expression Denial of Service via multiple wildcards ### Impact When using multiple wildcards, combined with at least one parameter, a regular expression can be generated that is vulnerable to ReDoS. This backtracking vulnerability requires the second wildcard to be somewhere other than the end of the path. **Unsafe examples:** ``` /*foo-*bar-:baz /*a-:b-*c-:d /x/*a-:b/*c/y ``` **Safe examples:** ``` /*foo-:bar /*foo-:bar-*baz ``` ### Patches Upgrade to version `8.4.0`. ### Workarounds If developers are using multiple wildcard parameters, they can check the regex output with a tool such as https://makenowjust-labs.github.io/recheck/playground/ to confirm whether a path is vulnerable.

8.4.0-1
Affected by 0 other vulnerabilities.

8.4.1-1
Affected by 0 other vulnerabilities.

Vulnerability	Summary	Aliases
VCID-2xgj-yjdf-nqeh	path-to-regexp contains a ReDoS ### Impact The regular expression that is vulnerable to backtracking can be generated in versions before 0.1.12 of `path-to-regexp`, originally reported in CVE-2024-45296 ### Patches Upgrade to 0.1.12. ### Workarounds Avoid using two parameters within a single path segment, when the separator is not `.` (e.g. no `/:a-:b`). Alternatively, you can define the regex used for both parameters and ensure they do not overlap to allow backtracking. ### References - https://github.com/advisories/GHSA-9wv6-86v2-598j - https://blakeembrey.com/posts/2024-09-web-redos/	CVE-2024-52798 GHSA-rhx6-c78j-4q9w
VCID-r95c-k4nq-jbd1	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/)	CVE-2024-45296 GHSA-9wv6-86v2-598j
VCID-vzcu-mpsr-qbgm	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](https://github.com/pillarjs/path-to-regexp/releases/tag/v.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](https://github.com/advisories/GHSA-9wv6-86v2-598j) - [Detailed blog post: ReDoS the web](https://blakeembrey.com/posts/2024-09-web-redos/)	CVE-2026-4867 GHSA-37ch-88jc-xwx2

Vulnerability

Summary

Aliases

VCID-2xgj-yjdf-nqeh

path-to-regexp contains a ReDoS ### Impact The regular expression that is vulnerable to backtracking can be generated in versions before 0.1.12 of `path-to-regexp`, originally reported in CVE-2024-45296 ### Patches Upgrade to 0.1.12. ### Workarounds Avoid using two parameters within a single path segment, when the separator is not `.` (e.g. no `/:a-:b`). Alternatively, you can define the regex used for both parameters and ensure they do not overlap to allow backtracking. ### References - https://github.com/advisories/GHSA-9wv6-86v2-598j - https://blakeembrey.com/posts/2024-09-web-redos/

CVE-2024-52798
GHSA-rhx6-c78j-4q9w

VCID-r95c-k4nq-jbd1

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/)

CVE-2024-45296
GHSA-9wv6-86v2-598j

VCID-vzcu-mpsr-qbgm

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](https://github.com/pillarjs/path-to-regexp/releases/tag/v.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](https://github.com/advisories/GHSA-9wv6-86v2-598j) - [Detailed blog post: ReDoS the web](https://blakeembrey.com/posts/2024-09-web-redos/)

CVE-2026-4867
GHSA-37ch-88jc-xwx2

Date	Actor	Action	Vulnerability	Source	VulnerableCode Version
2026-04-16T13:03:26.037929+00:00	Debian Importer	Fixing	VCID-2xgj-yjdf-nqeh	https://security-tracker.debian.org/tracker/data/json	38.4.0
2026-04-16T10:47:15.714224+00:00	Debian Importer	Fixing	VCID-vzcu-mpsr-qbgm	https://security-tracker.debian.org/tracker/data/json	38.4.0
2026-04-13T08:58:35.506558+00:00	Debian Importer	Fixing	VCID-2xgj-yjdf-nqeh	https://security-tracker.debian.org/tracker/data/json	38.3.0
2026-04-13T07:18:00.123982+00:00	Debian Importer	Fixing	VCID-vzcu-mpsr-qbgm	https://security-tracker.debian.org/tracker/data/json	38.3.0
2026-04-03T07:47:13.660029+00:00	Debian Importer	Affected by	VCID-1vjw-mm86-k7gn	https://security-tracker.debian.org/tracker/data/json	38.1.0
2026-04-03T07:47:13.614931+00:00	Debian Importer	Affected by	VCID-366w-k4rs-v7d3	https://security-tracker.debian.org/tracker/data/json	38.1.0
2026-04-03T07:47:13.590003+00:00	Debian Importer	Fixing	VCID-vzcu-mpsr-qbgm	https://security-tracker.debian.org/tracker/data/json	38.1.0
2026-04-03T07:47:13.548342+00:00	Debian Importer	Fixing	VCID-2xgj-yjdf-nqeh	https://security-tracker.debian.org/tracker/data/json	38.1.0
2026-04-03T07:47:13.506925+00:00	Debian Importer	Fixing	VCID-r95c-k4nq-jbd1	https://security-tracker.debian.org/tracker/data/json	38.1.0