CVE-2026-4867
Pillarjs Path-To-Regexp ≤ 0.1.13
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2026-4867 is a high-severity Inefficient Regular Expression Complexity (CWE-1333) vulnerability in Pillarjs Path-To-Regexp. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 40th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-4867 is a regular expression denial-of-service (ReDoS) vulnerability in the path-to-regexp JavaScript library, affecting versions prior to 0.1.13. The issue arises when generating regular expressions for route patterns containing three or more parameters within a single segment, separated by characters other than periods, such as /:a-:b-:c or /:a-:b-:c-:d. While backtrack protection was added in version 0.1.12 to handle ambiguity for two parameters, it fails for three or more, as the lookahead does not block single separator characters. This causes capture groups to overlap, triggering catastrophic backtracking. The vulnerability is rated with a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and is associated with CWE-1333 (Inefficient Regular Expression Complexity).
Remote, unauthenticated attackers can exploit this vulnerability by sending specially crafted URLs matching the affected route patterns. The malicious input triggers excessive backtracking in the regex engine during route matching, consuming significant CPU resources and potentially causing the application server to become unresponsive or crash, resulting in a denial of service.
Advisories recommend upgrading to path-to-regexp@0.1.13, which addresses the regex generation flaw. Custom regex patterns in route definitions, such as /:a-:b([^-/]+)-:c([^-/]+), are unaffected as they override the default capture groups. Workarounds include providing custom regular expressions for parameters after the first in a segment—ensuring they do not match preceding text—or limiting URL length if paths cannot be rewritten and upgrades are not feasible. Further details are available in the referenced advisories at https://blakeembrey.com/posts/2024-09-web-redos, https://cna.openjsf.org/security-advisories.html, and https://github.com/advisories/GHSA-9wv6-86v2-598j.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-16273
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover inefficient regex patterns via performance or static analysis.
Development standards and tools can require safe regex construction and forbid known exponential patterns.
Denial-of-service protections limit resource exhaustion caused by expensive regex evaluation.
Input validation can constrain data that would otherwise trigger worst-case regex complexity.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect and reject regex patterns with exponential worst-case complexity.
Secure development lifecycle mandates review of algorithmic efficiency, directly addressing ReDoS-prone regex.
Application security requirements can specify input-validation rules that limit regex complexity.
Secure architecture principles encourage avoidance of computationally expensive constructs such as catastrophic backtracking.
Secure coding standards explicitly prohibit or limit the use of inefficient regular expressions.