CVE-2024-52798

What it actually does

This is a regular expression denial-of-service vulnerability in path-to-regexp 0.1.x. The library converts route path patterns into JavaScript regular expressions; in certain route configurations it can generate expressions with excessive backtracking behavior. A remote, unauthenticated attacker can send specially crafted request paths that match affected routes poorly and force the Node.js event loop to spend excessive CPU time evaluating the generated regular expression. The primary impact is availability loss: requests may become slow, worker processes may peg CPU, health checks may fail, and services may restart or stop responding. The issue is an incomplete fix for CVE-2024-45296.

Why it matters to the business

Applications that rely on vulnerable path-to-regexp versions for HTTP routing can be made slow or unavailable with network requests, potentially causing customer-facing outages, failed API calls, degraded service-level objectives, and increased infrastructure cost from autoscaling or restarts. The CVSS availability impact is high, but the current EPSS is low and it is not listed in CISA KEV or known ransomware use, so remediation should be prioritized based on internet exposure and dependency reach rather than active mass exploitation signals.

How an attack unfolds

An attacker first identifies an application or API endpoint whose routing stack uses path-to-regexp 0.1.x and contains a route pattern that compiles into a vulnerable backtracking regular expression. The attacker then sends HTTP requests with intentionally malformed, overlong, or near-matching path strings designed to trigger worst-case regular-expression evaluation. Because JavaScript regular expression execution can block the Node.js event loop, even a small number of requests may consume significant CPU and prevent legitimate requests from being processed. If the service is behind a load balancer or orchestrator, the visible symptoms may include elevated latency, upstream timeouts, 5xx responses, failed liveness probes, container restarts, or horizontal scaling without a corresponding increase in legitimate traffic.

How to fix it

Upgrade path-to-regexp 0.1.x to version 0.1.12 or later. For source-based remediation, use the fixed upstream commit 640e694c6fd971f78268439df9cf44040855e669 where applicable. Regenerate lockfiles and rebuild applications so the patched dependency is actually deployed, including transitive dependencies bundled through web frameworks. If vulnerability management tooling reports affected Ubuntu ImageMagick packages, apply the vendor-fixed packages: Ubuntu 14.04 LTS fixed in 8:6.7.7.10-6ubuntu3.2 and Ubuntu 16.04 LTS fixed in 8:6.8.9.9-7ubuntu5. Mitigations where immediate upgrade is not possible include enforcing maximum URL length at reverse proxies and application gateways, rejecting abnormal path patterns early, applying per-IP and per-route rate limits, isolating Node.js worker processes, and ensuring health checks and autoscaling do not amplify the impact of CPU exhaustion.

How to confirm the fix worked

Confirm that no deployed application resolves path-to-regexp to a vulnerable 0.1.x version below 0.1.12. Check package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOMs, container images, and runtime node_modules directories. Validate with commands such as npm ls path-to-regexp, yarn why path-to-regexp, or pnpm why path-to-regexp in each application build context. After remediation, run dependency scans against rebuilt artifacts rather than only source repositories. Operationally, perform safe staging tests with long and malformed request paths against representative routes and verify that CPU usage, event-loop lag, latency, and error rates remain bounded. For Ubuntu packages, verify installed versions with dpkg -l or apt-cache policy and ensure the fixed vendor versions or later are installed.

Typical attack path

1. Discover internet-facing web applications or APIs using Node.js routing frameworks or other software that bundles path-to-regexp 0.1.x.
2. Identify routes whose path patterns are likely to compile into vulnerable regular expressions.
3. Send crafted HTTP requests with long or pathological URL paths that nearly match affected route expressions.
4. Force excessive regular-expression backtracking in the request-routing layer.
5. Consume CPU and block request processing in the Node.js event loop.
6. Repeat requests or distribute them across endpoints to sustain service degradation or outage.

How to detect it

To assess possible prior exploitation, review web server, reverse proxy, CDN, WAF, API gateway, and application logs for bursts of unusually long or malformed URL paths followed by latency increases, 499/502/503/504 responses, upstream timeout messages, failed health checks, or service restarts. Correlate these events with host and container telemetry showing high CPU in Node.js processes, elevated event-loop lag, increased garbage collection pressure, pod restarts, or autoscaling activity without matching legitimate traffic growth. Application performance monitoring traces may show time concentrated in routing or request dispatch before controller logic is reached. Because this vulnerability causes resource exhaustion rather than code execution, durable host artifacts are usually absent; detection depends mainly on traffic patterns and availability telemetry. There are no known named threat actors, KEV exploitation, or ransomware campaigns tied to this CVE in the supplied data.

• node_modules/path-to-regexp/package.json
• "path-to-regexp": "0.1.
• path-to-regexp@0.1.
• GET /%2F%2F%2F
• GET /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
• POST /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
• upstream timed out
• connect() failed (110: Connection timed out) while reading response header from upstream
• HTTP 503
• HTTP 504
• JavaScript heap out of memory
• event loop lag
• npm ls path-to-regexp

What your security team should do

• Inventory all applications, containers, and serverless functions that include path-to-regexp, especially transitive use through Express-compatible routing stacks.
• Prioritize patching internet-facing Node.js APIs and services where route matching occurs before authentication or rate limiting.
• Upgrade to path-to-regexp 0.1.12 or later, regenerate lockfiles, rebuild artifacts, and redeploy rather than relying on source manifest changes alone.
• Add reverse-proxy controls for maximum request URI length, request rate, and abnormal path rejection to reduce exposure to regex-based denial-of-service attacks.
• Monitor for Node.js CPU spikes, event-loop lag, upstream timeouts, and bursts of long unusual URL paths, even though there is no public KEV listing or known ransomware association.
• Review whether scanners are reporting distro package mappings such as Ubuntu ImageMagick and apply the corresponding vendor updates where those packages are present.
• Create regression tests for route patterns that accept broad or repeated path segments so future routing changes do not reintroduce catastrophic backtracking behavior.