Path-to-regexp vulnerabilities
Published CVEs affecting Path-to-regexp products: 3 record(s), with severity, exploitation and fixes.
CVE-2026-4926
High · 7.5
CWE-400 Mar 26, 2026
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.
CVE-2026-4923
Medium · 5.9
CWE-1333 Mar 26, 2026
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 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.
CVE-2026-4867
High · 7.5
CWE-1333 Mar 26, 2026
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.