Path To Regexp
Approved changes feed: RSS · Atom
cpe:2.3:a:pillarjs:path-to-regexp:*:*:*:*:*:node.js:*:*
part: a version: * update: *
| Vendor | Pillarjs (cc447f9a-ae88-52ad-b549-a3fb2cf56894) |
|---|---|
| Product | Path To Regexp (1f9a9be2-82c7-5421-b5e9-db9527381ed1) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | node.js |
| Target hardware | * |
| Other | * |
| Notes | Imported from gcve-enriched-dumps CVE data |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
pkg:github/pillarjs/path-to-regexp |
purl2cpe | 2026-06-19 13:12:40.940494 |
pkg:npm/path-to-regexp |
purl2cpe | 2026-06-19 13:12:40.940495 |
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-4926 |
vulnerable | 2026-06-08 08:07:02.675217 |
path-to-regexp vulnerable to Denial of Service via sequential optional groups
HIGH (7.5)
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.
Published: 2026-03-26T18:59:38.000Z
Updated: 2026-08-25T12:05:56.696Z Reference links |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-4923 |
vulnerable | 2026-06-08 08:07:02.673950 |
path-to-regexp vulnerable to Regular Expression Denial of Service via multiple wildcards
MEDIUM (5.9)
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 you are using multiple wildcard parameters, you can check the regex output with a tool such as https://makenowjust-labs.github.io/recheck/playground/ to confirm whether a path is vulnerable.
Published: 2026-03-26T19:02:00.729Z
Updated: 2026-03-27T13:58:03.925Z Reference links |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-4867 |
vulnerable | 2026-06-08 08:07:02.560491 |
path-to-regexp vulnerable to Regular Expression Denial of Service via multiple route parameters
HIGH (7.5)
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.
Published: 2026-03-26T16:16:25.501Z
Updated: 2026-03-26T16:52:14.893Z |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.