CVE-2026-4923

What it actually does

This is a regular expression denial-of-service vulnerability in pillarjs path-to-regexp. Certain route patterns containing multiple wildcards plus at least one named parameter can cause path-to-regexp to generate a regular expression with catastrophic backtracking behavior. The vulnerable condition requires a second wildcard that is not positioned at the end of the path. When an unauthenticated remote client sends a specially crafted URL path that nearly matches one of these generated route expressions, the application process can spend excessive CPU time evaluating the regex, degrading or blocking request handling. The impact is availability loss only; the flaw does not directly enable data disclosure, authentication bypass, or code execution.

Why it matters to the business

Applications that use vulnerable route patterns may become slow or unavailable when exposed to crafted HTTP requests. The operational impact can include elevated CPU usage, request timeouts, failed health checks, service degradation, autoscaling events, and denial of service for legitimate users. The CVSS score is moderate, EPSS is currently low, it is not listed in CISA KEV, and there is no known exploit maturity in the provided data, but internet-facing services using affected routing patterns should still be prioritized because exploitation is remote and does not require authentication.

How an attack unfolds

An attacker first identifies an application or API that uses path-to-regexp for routing and has route definitions matching the vulnerable shape: multiple wildcard parameters combined with at least one named parameter, where the second wildcard is not at the end of the path. The attacker then sends HTTP requests with long, carefully structured path strings that force the generated regular expression engine into excessive backtracking. Each malicious request consumes disproportionate CPU time in the application process while the router attempts to match the path. By repeating these requests or sending them concurrently, the attacker can exhaust worker capacity, cause high latency, trigger timeouts, and potentially make the service unavailable. Because the flaw affects routing evaluation, exploitation can occur before normal application-level authorization logic is reached.

How to fix it

Upgrade pillarjs path-to-regexp to version 8.4.0 or later wherever it is used directly or transitively. If immediate upgrade is not possible, review route definitions and remove or refactor vulnerable patterns containing multiple wildcards plus parameters, especially patterns where the second wildcard is not at the end of the path. Avoid route structures like /*foo-*bar-:baz, /*a-:b-*c-:d, and /x/*a-:b/*c/y. Prefer safer route forms such as a single wildcard combined with parameters, or place wildcard constructs so they do not generate ambiguous backtracking-heavy expressions. As an interim control, validate generated regular expressions with a ReDoS analysis tool, apply request path length limits, enforce rate limits, and configure upstream proxies or load balancers to reject excessively long or abnormal URL paths.

How to confirm the fix worked

Confirm that all deployed applications and build artifacts resolve pillarjs path-to-regexp to version 8.4.0 or later. Use package manager commands such as npm ls path-to-regexp, yarn why path-to-regexp, or pnpm why path-to-regexp to identify direct and transitive usage. Review application route definitions for vulnerable wildcard-plus-parameter combinations and confirm they have been removed, refactored, or regenerated using the fixed library. In staging, send representative long-path requests to formerly vulnerable routes and verify that CPU usage, latency, and error rates remain stable. Also confirm upstream protections such as path length limits and rate limits are active and do not break legitimate traffic.

Typical attack path

1. Discover or infer that the target application uses routes generated by vulnerable versions of pillarjs path-to-regexp.
2. Identify or guess endpoints whose route patterns contain multiple wildcards and at least one parameter, with the second wildcard not at the end of the path.
3. Generate long URL paths designed to nearly match the vulnerable route expression and trigger catastrophic backtracking.
4. Send crafted HTTP requests repeatedly or concurrently to the vulnerable endpoint.
5. Cause high CPU usage in the application process, increased response latency, request timeouts, failed health checks, or service unavailability.

How to detect it

Look for evidence of attempted or successful denial of service rather than file-based compromise. Relevant sources include reverse proxy logs, CDN/WAF logs, web server access logs, application logs, APM traces, container or host CPU metrics, event-loop latency metrics for Node.js applications, load balancer health-check logs, and autoscaling events. Hunt for repeated requests with unusually long URL paths, high request rates to the same endpoint, requests that produce long response times or upstream timeouts, and clusters of 408, 429, 499, 500, 502, 503, or 504 responses. Correlate these requests with spikes in CPU utilization, Node.js event-loop delay, process restarts, failed readiness/liveness probes, and degraded response latency. Review deployed route patterns for exposure; exploitation is most plausible where unsafe patterns with multiple wildcards and parameters are reachable from untrusted clients. There are no known named threat actors, KEV listing, ransomware usage, or public exploit maturity in the supplied data, so prioritize behavioral detection over signature-only detection.

What your security team should do

• Inventory all applications, APIs, frameworks, and middleware that include pillarjs path-to-regexp, including transitive dependencies bundled through web frameworks.
• Upgrade affected dependency trees to path-to-regexp 8.4.0 or later and redeploy affected services.
• Prioritize internet-facing services and high-traffic APIs because the issue can be triggered remotely without authentication.
• Search route definitions for multiple wildcard parameters combined with named parameters, especially where the second wildcard is not at the end of the route.
• Temporarily mitigate with request path length limits, rate limiting, WAF or reverse-proxy rules for abnormal long paths, and autoscaling/health-check monitoring until upgrades are complete.
• Monitor application CPU saturation, event-loop delay, request latency, 408/429/499/500/502/503/504 responses, and repeated long URL path requests to detect attempted denial-of-service activity.
• Add regression tests or static checks to prevent introduction of unsafe route patterns in future releases.