Every CVE Search/ Get API key

CVE-2026-4867

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

7.5 HighFix available

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 [email protected] 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 [email protected]

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
None
Integrity
None
Availability
High

Exploit likelihood

0.52%Up 0.5 points since Mar 27, 2026
90%50%10%1%

What each source reports

CVE List Score used 7.5

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 [email protected] 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 [email protected]

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.

Record
CVE-2026-4867
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-1333
Updated
2026-11-02
EUVDEUVD-2026-16273 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 [email protected] 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 [email protected]

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.

Record
EUVD-2026-16273
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated
2026-11-02
GitHub AdvisoriesGHSA-37ch-88jc-xwx2 7.5

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 [email protected] 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 [email protected]

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

Record
GHSA-37ch-88jc-xwx2
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-1333
Updated
2026-11-02
NVD 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 [email protected] 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 [email protected]

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.

Record
CVE-2026-4867
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-1333
Updated
2026-11-02
OSVCVE-2024-45296 7.5

path-to-regexp outputs backtracking regular expressions

path-to-regexp turns path strings into a regular expressions. In certain cases, path-to-regexp will output a regular expression that can be exploited to cause poor performance. Because JavaScript is single threaded and regex matching runs on the main thread, poor performance will block the event loop and lead to a DoS. The bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (.). For users of 0.1, upgrade to 0.1.10. All other users should upgrade to 8.0.0.

Record
CVE-2024-45296
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-1333
Updated
2026-11-02
OSV 7.5

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 [email protected] 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 [email protected]

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.

Record
CVE-2026-4867
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-1333
Updated
2026-11-02
Show 9 moreShow less
OSVDEBIAN-CVE-2026-4867 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 [email protected] 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 [email protected] 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.

Record
DEBIAN-CVE-2026-4867
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated
2026-11-02
OSVGHSA-37ch-88jc-xwx2 7.5

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 [email protected] 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 [email protected]

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

Record
GHSA-37ch-88jc-xwx2
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-1333
Updated
2026-11-02
OSVGHSA-9wv6-86v2-598j 7.7

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:

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 can enable strict: true and get an error when the regular expression might be bad.

Version 8.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 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

Record
GHSA-9wv6-86v2-598j
CVSS 4.0
7.7 HighCVSS: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
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-1333
Updated
2026-11-02
OSVROOT-APP-NPM-CVE-2026-4867 7.5

CVE-2026-4867 in @rootio/path-to-regexp - Patched by Root

Root has patched CVE-2026-4867 in the @rootio/path-to-regexp package for Root:npm. Multiple fixed versions available.

Record
ROOT-APP-NPM-CVE-2026-4867
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated
2026-11-02
OSVUBUNTU-CVE-2026-4867 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 [email protected] 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 [email protected] 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.

Record
UBUNTU-CVE-2026-4867
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated
2026-11-02
OSVCLSA-2026-1777250311 No score

TuxCare security update for path-to-regexp (1 CVE)

TuxCare rebuilt path-to-regexp to address 1 CVE. Fixed in 0.1.3-tuxcare.2.

Record
CLSA-2026-1777250311
Updated
2026-11-02
OSVCLSA-2026-1779238048 No score

TuxCare security update for path-to-regexp (1 CVE)

TuxCare rebuilt path-to-regexp to address 1 CVE. Fixed in 0.1.12-tuxcare.1.

Record
CLSA-2026-1779238048
Updated
2026-11-02
OSVCLSA-2026-1792663862 No score

TuxCare security update for path-to-regexp (1 CVE)

TuxCare rebuilt path-to-regexp to address 1 CVE. Fixed in 0.1.7-tuxcare.2.

Record
CLSA-2026-1792663862
Updated
2026-11-02
OSVCLSA-2026-1792789806 No score

TuxCare security update for path-to-regexp (1 CVE)

TuxCare rebuilt path-to-regexp to address 1 CVE. Fixed in 0.1.10-tuxcare.3.

Record
CLSA-2026-1792789806
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
path-to-regexp
npm
before 0.1.13
0.1.13
path-to-regexp
TuxCare:npm
0.1.3-tuxcare.0 up to 0.1.3-tuxcare.2, plus listed versions
0.1.30.1.3-tuxcare.1
0.1.3-tuxcare.2
path-to-regexp
TuxCare:npm
0.1.12-tuxcare.0 up to 0.1.12-tuxcare.1, plus listed versions
0.1.12
0.1.12-tuxcare.1
path-to-regexp
TuxCare:npm
0.1.7-tuxcare.0 up to 0.1.7-tuxcare.2, plus listed versions
0.1.70.1.7-tuxcare.1
0.1.7-tuxcare.2
path-to-regexp
TuxCare:npm
0.1.10-tuxcare.0 up to 0.1.10-tuxcare.3, plus listed versions
0.1.100.1.10-tuxcare.10.1.10-tuxcare.2
0.1.10-tuxcare.3
node-path-to-regexp
Debian:12
before 1.0.1-1
1.0.1-1
node-path-to-regexp
Debian:13
before 1.0.1-1
1.0.1-1
node-path-to-regexp
Debian:14
before 1.0.1-1
1.0.1-1
path-to-regexp
npm
From an advisory covering 2 CVEs
before 0.1.13
0.1.13
path-to-regexp
npm
From an advisory covering 2 CVEs
0.2.0 up to 1.9.0
1.9.0
Show 6 moreShow less
Affected packages
PackageAffectedFixed
path-to-regexp
npm
From an advisory covering 2 CVEs
before 0.1.10
0.1.10
path-to-regexp
npm
From an advisory covering 2 CVEs
7.0.0 up to 8.0.0
8.0.0
path-to-regexp
npm
From an advisory covering 2 CVEs
2.0.0 up to 3.3.0
3.3.0
path-to-regexp
npm
From an advisory covering 2 CVEs
4.0.0 up to 6.3.0
6.3.0
@rootio/path-to-regexp
Root:npm
before 0.1.12-root.io.1
0.1.12-root.io.10.1.12-root.io.20.1.10-root.io.20.1.10-root.io.10.1.10-root.io.3
path-to-regexp
Root:npm
before 0.1.12-aikido.2
0.1.12-aikido.20.1.10-aikido.20.1.10-aikido.10.1.10-aikido.3

History

History
RecordedChangedSources
affected, facts
affected
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-4867 is a high vulnerability (CVSS 7.5) in Path-to-regexp, published September 9, 2024. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.52%, the 44th percentile. Fixed in path-to-regexp 0.1.13.

References

Show 16 moreShow less
MoveEnter Open