CVE-2026-4867

What it actually does

This vulnerability is a regular expression denial-of-service flaw in pillarjs path-to-regexp. When an application defines a route segment containing three or more parameters separated by a non-period character, such as /:a-:b-:c, the library can generate an ambiguous regular expression. The backtracking protection introduced in path-to-regexp 0.1.12 only addresses ambiguity involving two parameters; with three or more parameters, overlapping capture groups can trigger catastrophic backtracking when processing crafted request paths. A remote unauthenticated attacker can send specially constructed URLs that consume excessive CPU during route matching, causing high latency or denial of service. The issue affects availability only; it does not directly provide code execution, data access, or privilege escalation.

Why it matters to the business

Public-facing web applications, APIs, and services that use affected path-to-regexp route definitions may become slow or unavailable if attackers send maliciously crafted URLs. The operational impact can include failed customer requests, API outages, increased infrastructure costs from CPU exhaustion, autoscaling events, degraded service-level objectives, and noisy incident response. The current EPSS score is low and it is not listed in CISA KEV or reported as ransomware-used, but the vulnerability is network-exploitable, unauthenticated, low-complexity, and can affect widely deployed JavaScript web stacks, so internet-facing services should still be remediated promptly.

How an attack unfolds

An attacker first identifies an application endpoint whose routing layer uses path-to-regexp and contains a vulnerable route pattern with three or more parameters in a single path segment separated by a character other than a period, for example hyphens. The attacker then sends long or carefully shaped path strings to that endpoint so that the generated regular expression attempts many overlapping matches. Because the capture groups are ambiguous, the regular expression engine performs excessive backtracking before rejecting or resolving the route. Repeating these requests, or sending them concurrently, can pin server CPU and slow or block request handling for legitimate users. No authentication or user interaction is required if the vulnerable route is exposed publicly.

How to fix it

Upgrade pillarjs path-to-regexp to version 0.1.13 or later where available. If using a framework or transitive dependency that bundles path-to-regexp, upgrade the parent framework/package to a version that includes path-to-regexp 0.1.13 or a fixed equivalent. Review route definitions for single path segments containing three or more parameters separated by non-period delimiters, such as /:a-:b-:c or /:a-:b-:c-:d. As a workaround, rewrite vulnerable routes to use custom regular expressions for parameters after the first so they cannot match the separator text, for example /:a-:b([^-/]+)-:c([^-/]+). Custom regex patterns that safely constrain the parameter content are not affected. If immediate code changes are not possible, enforce conservative URL length limits at the reverse proxy, load balancer, WAF, or application layer, and consider rate limiting anomalous requests to affected routes.

How to confirm the fix worked

Confirm dependency resolution shows path-to-regexp 0.1.13 or later, including transitive dependency lockfiles such as package-lock.json, yarn.lock, pnpm-lock.yaml, or npm ls output. Review application route definitions and generated routes for patterns with three or more parameters in a single segment separated by non-period characters. Validate that such routes have been removed, rewritten with safe custom regex constraints, or are no longer reachable. In staging, test representative long malformed URL paths against formerly vulnerable routes and confirm they are rejected quickly without excessive CPU usage or request latency. Confirm reverse proxy, WAF, or application URL length controls are active if used as mitigation.

Typical attack path

1. Identify a web application or API using path-to-regexp-based routing, commonly in Node.js/Express-style stacks.
2. Find or infer routes with three or more parameters in one segment separated by a non-period character, such as /:a-:b-:c.
3. Send crafted long URL paths targeting the vulnerable route shape to trigger catastrophic regex backtracking during route matching.
4. Repeat requests or distribute them across connections to sustain high CPU consumption.
5. Cause degraded response times, request timeouts, service instability, or outage.

How to detect it

To determine whether exploitation has already occurred, review web server, reverse proxy, CDN, WAF, and application access logs for unusually long request paths targeting endpoints that resemble multi-parameter route segments, especially paths containing repeated hyphen-separated values in a single segment. Correlate suspicious requests with application CPU spikes, event-loop delay, request timeouts, elevated 502/503/504 responses, container restarts, autoscaling events, or Node.js process saturation. Look for bursts of unauthenticated requests from the same source or distributed sources where the URI path is much longer than normal and contains repeated separator-delimited tokens. Application logs may not show a stack trace because the impact occurs during route matching, but performance monitoring may show long request durations before routing or handler execution. If available, use APM traces, Node.js CPU profiles, reverse proxy timing fields, and WAF logs to identify whether long path requests coincide with degraded availability.

• path-to-regexp@0.1.12
• /:a-:b-:c
• /:a-:b-:c-:d
• /[^ ?]{2000,}
• /[^/ ?]+-[^/ ?]+-[^/ ?]+-[^/ ?]+
• HTTP 414
• HTTP 502
• HTTP 503
• HTTP 504
• upstream timed out
• request timed out
• Node.js event loop delay
• npm ls path-to-regexp

What your security team should do

• Inventory applications and APIs that depend on pillarjs path-to-regexp directly or through Node.js web frameworks.
• Prioritize internet-facing services and high-traffic APIs for upgrade to path-to-regexp 0.1.13 or a parent package version that includes the fix.
• Search source code and route registries for single-segment route patterns with three or more colon parameters separated by hyphens or other non-period delimiters.
• Apply safe route rewrites using explicit custom regex constraints where immediate dependency upgrades are blocked.
• Deploy URL length limits and request rate limiting as compensating controls for exposed services until code fixes are complete.
• Monitor access logs and application performance metrics for spikes in long malformed URL paths, elevated 4xx/5xx responses, request timeouts, and CPU saturation.
• Because this is not currently KEV-listed and has low EPSS, treat it as priority remediation for exposed or performance-sensitive services rather than an emergency across all assets.