path-to-regexp vulnerable to Regular Expression Denial of Service via multiple route parameters

Summary

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.

Timeline

1. Mar 26, 2026, 4:16 PM UTCCVE published
2. Mar 26, 2026, 4:52 PM UTCCISA SSVC assessment

   Exploitation: none · Automatable: yes · Technical impact: partial

3. Mar 26, 2026, 4:52 PM UTCRecord last updated

Affected versions

• path-to-regexp path-to-regexp

  fixed in 0.1.13

• path-to-regexpnpm

  From 0.2.0 · fixed in 1.9.0

• path-to-regexpnpm

  fixed in 0.1.10

• path-to-regexpnpm

  From 7.0.0 · fixed in 8.0.0

• path-to-regexpnpm

  From 2.0.0 · fixed in 3.3.0

• path-to-regexpnpm

  From 4.0.0 · fixed in 6.3.0

• path-to-regexpnpm

  fixed in 0.1.13

References 3