CVE-2024-45296

What it actually does

This is a regular-expression denial-of-service vulnerability in pillarjs/path-to-regexp, a library used to convert route path strings into JavaScript regular expressions. When an application defines a route segment containing two parameters separated by a character other than a period, such as a dash or other delimiter, affected versions can generate a regex with poor worst-case matching behavior. An unauthenticated remote requester may be able to send crafted URL paths that force expensive regex evaluation. Because regex matching in Node.js runs on the main JavaScript thread, a single expensive match can block the event loop, delaying or preventing the application from processing other requests. The impact is availability loss only; the flaw does not directly provide code execution, data disclosure, or data modification.

Why it matters to the business

Internet-facing Node.js services that use affected path-to-regexp versions may become slow or unavailable if exposed routes are susceptible and receive crafted requests. The operational effect can include elevated latency, request timeouts, failed health checks, autoscaling churn, degraded API availability, and potential service-level objective or contractual availability impact. The issue has a high availability CVSS impact but is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported public exploit maturity in the provided data, so it should be prioritized as a resilience and dependency hygiene fix rather than treated as confirmed active exploitation.

How an attack unfolds

An attacker first identifies an application endpoint whose routing is built through an affected path-to-regexp version and whose route definition contains two parameters in a single path segment separated by a non-period delimiter. The attacker then sends specially shaped and often long URL paths that nearly match the generated route expression but trigger excessive backtracking or otherwise poor regex performance. Each malicious request can consume disproportionate CPU on the Node.js main thread while the application attempts to match the route. If repeated or combined with concurrency, these requests block the event loop, causing normal user requests to queue, time out, or fail. Successful exploitation results in denial of service for the affected process or service tier, not compromise of confidentiality or integrity.

How to fix it

Upgrade path-to-regexp to a fixed version. Users of the 0.1.x line should upgrade to 0.1.10. All other users should upgrade to 8.0.0 or later where compatible. The upstream Git fix is associated with commit c827fcea751b2e9ec6ca68a1b95a82e438728868. Because path-to-regexp is frequently present as a transitive dependency through web frameworks and routers, update both direct and transitive dependencies, regenerate lockfiles, and redeploy rebuilt artifacts. If immediate upgrade is not possible, review route definitions and avoid patterns with two parameters in the same segment separated by a non-period delimiter; split the segment, use a period separator where semantically safe, or replace ambiguous dynamic route patterns with stricter explicit validation. Add request-size limits, URL path length limits, rate limiting, and upstream timeout controls at reverse proxies, load balancers, and API gateways to reduce exploitability. Ensure Node.js services have process supervision and horizontal capacity so a blocked event loop does not take down an entire service.

How to confirm the fix worked

Confirm dependency resolution shows a fixed path-to-regexp version in package manifests and lockfiles: 0.1.10 for the 0.1 branch or 8.0.0 or later for other supported branches. Use package-manager tooling such as npm ls path-to-regexp, yarn why path-to-regexp, pnpm why path-to-regexp, or software composition analysis to verify there are no remaining vulnerable transitive copies in the deployed artifact. Review application route definitions for single path segments containing multiple parameters separated by non-period delimiters and confirm they were removed, changed, or protected. In a non-production test environment, exercise formerly susceptible routes with long malformed path inputs and verify that CPU usage, event-loop delay, and response latency remain bounded. Validate compensating controls by confirming maximum URL length, request rate limits, and gateway timeouts are enforced before requests reach the Node.js application.

Typical attack path

1. Reconnoiter externally reachable Node.js or JavaScript-backed HTTP services and enumerate routes or infer route patterns from API behavior, documentation, client-side code, or error responses.
2. Identify candidate routes that may correspond to path-to-regexp patterns with two parameters in one segment separated by a non-period delimiter, such as a dash-delimited pair.
3. Send crafted long or edge-case URL paths to the candidate routes while observing response latency, timeout behavior, and server availability.
4. Increase request length, repetition, or concurrency to amplify CPU consumption in regex matching.
5. Cause the Node.js event loop to become blocked, resulting in degraded service, failed requests, or process restarts depending on the deployment and health-check configuration.

How to detect it

Retrospective exploitation detection is behavioral because there is no universal exploit payload: the malicious URL depends on each application’s route definitions. Review HTTP access logs, reverse proxy logs, CDN/WAF logs, API gateway logs, application logs, APM traces, and Node.js runtime metrics for periods of high CPU, elevated event-loop lag, request latency spikes, and increased 5xx or timeout responses that correlate with repeated long or unusual URL paths. Focus on routes that contain multiple dynamic-looking values in a single segment separated by a dash or other non-period delimiter. Look for repeated requests from the same source IPs, user agents, autonomous systems, or bot infrastructure that produce slow responses without high request volume. Examine container, orchestrator, and process-manager events for restarts, liveness probe failures, out-of-memory misattribution, or CPU throttling that occurred at the same time as suspicious path requests. If packet captures or WAF logs are available, search for very long path segments, high-entropy path components, excessive repeated characters, and malformed near-matches to known route patterns. Treat findings as suspected denial-of-service activity when abnormal URL patterns align temporally with event-loop blocking or availability degradation.

What your security team should do

• Inventory applications and container images that include path-to-regexp, including transitive copies pulled in by routing frameworks.
• Prioritize internet-facing Node.js services, APIs, developer portals, and edge services where route matching occurs before authentication or authorization.
• Upgrade to path-to-regexp 0.1.10 for 0.1.x users or 8.0.0 or later for other users, then rebuild and redeploy affected services.
• Search code repositories for route definitions with two parameters in one path segment separated by non-period delimiters and require safer route patterns during code review.
• Add or verify upstream controls for maximum URL length, request rate limiting, per-request timeouts, and bot or abusive traffic filtering.
• Monitor post-remediation for abnormal spikes in long URL paths, elevated event-loop delay, CPU saturation, HTTP 408/429/500/502/503/504 responses, and service restarts.
• Because this issue is not KEV-listed and has low EPSS in the provided data, schedule remediation promptly through normal vulnerability management unless the affected service is business-critical or publicly exposed, in which case expedite.