CVE-2024-45590

What it actually does

body-parser versions before 1.20.3 can be forced into excessive resource consumption when parsing URL-encoded request bodies. An unauthenticated remote attacker can send specially crafted application/x-www-form-urlencoded payloads, typically at volume, to endpoints that use body-parser's urlencoded middleware. The vulnerable parsing path can consume disproportionate CPU, memory, or event-loop time, causing slow responses, request timeouts, process instability, or service unavailability. The issue affects applications that include vulnerable body-parser versions and enable URL-encoded body parsing.

Why it matters to the business

Public-facing Node.js and Express applications using vulnerable body-parser versions may become unavailable under attack, disrupting login flows, form submissions, APIs, checkout paths, administrative portals, or other HTTP services that accept URL-encoded input. The EPSS score is low and this is not in CISA KEV, indicating no broad confirmed exploitation signal at this time, but the exposure is operationally meaningful because denial-of-service attacks can be simple to automate and may require no authentication.

How an attack unfolds

An attacker first identifies an application endpoint that accepts POST, PUT, or similar HTTP requests with Content-Type: application/x-www-form-urlencoded. If that endpoint is backed by vulnerable body-parser middleware with URL-encoded parsing enabled, the attacker sends crafted URL-encoded bodies designed to stress the parser. The attacker then repeats these requests from one host or a distributed set of clients to increase CPU, memory pressure, or event-loop blocking in the Node.js process. As the server spends excessive time parsing malicious input, legitimate requests queue, time out, or fail. If process managers or orchestrators repeatedly restart unhealthy instances, the attack may create cascading degradation across the application tier.

How to fix it

Upgrade body-parser to version 1.20.3 or later. For source-based consumers, ensure the fix corresponding to expressjs/body-parser commit 17529513673e39ba79886a7ce3363320cf1c0c50 is present. Rebuild and redeploy applications so the updated dependency is actually in the runtime artifact, container image, or serverless package. If Express is pulling body-parser transitively, update the lockfile and verify the resolved package version. As compensating controls, enforce strict request body size limits, parameter limits, request timeouts, reverse-proxy buffering limits, per-IP and per-route rate limits, and WAF/CDN rules for abnormal URL-encoded request volume. Disable urlencoded parsing on routes that do not need it, and prefer route-specific parsers rather than global middleware where possible.

How to confirm the fix worked

Confirm the installed dependency version with package manager and build artifact checks, such as npm ls body-parser, npm audit, yarn why body-parser, pnpm why body-parser, package-lock.json, yarn.lock, pnpm-lock.yaml, container SBOMs, or deployed image scans. Verify body-parser resolves to 1.20.3 or later, or that the patched commit is included for source builds. Exercise application endpoints that accept URL-encoded input with legitimate form submissions to ensure behavior is unchanged. Confirm reverse proxies and application middleware enforce maximum body size, parameter count, request duration, and concurrency limits. In staging, perform controlled load testing with URL-encoded requests and verify CPU, memory, event-loop delay, and error rates remain within expected thresholds.

Typical attack path

1. Reconnoiter the application for endpoints that accept URL-encoded form submissions or API requests.
2. Confirm the service is likely Node.js/Express or otherwise uses body-parser-style request parsing.
3. Send crafted application/x-www-form-urlencoded request bodies to endpoints where urlencoded parsing is enabled.
4. Increase request rate, concurrency, body size, or payload complexity to exhaust CPU, memory, or event-loop capacity.
5. Observe degraded responses, elevated latency, HTTP 5xx/timeout responses, or process restarts.
6. Continue or distribute the traffic to sustain denial of service against the affected application.

How to detect it

Review web server, reverse proxy, CDN/WAF, load balancer, and application logs for unusual bursts of POST or PUT requests with Content-Type: application/x-www-form-urlencoded, especially to form-handling endpoints, login endpoints, search endpoints, API endpoints, or any route using URL-encoded parsing. Look for high request concurrency from a single IP, many IPs with similar request patterns, abnormal request body sizes, unusually high parameter counts, repeated 400/413/429/499/500/502/503/504 responses, upstream timeouts, client disconnects, and request durations that increase sharply before failures. On hosts and containers, correlate suspected traffic windows with Node.js CPU saturation, memory growth, event-loop lag, garbage collection pressure, process restarts, OOM kills, crash loops, or autoscaling events. In application telemetry, search for body-parser errors, request entity size errors, malformed URL-encoded body parsing failures, and latency spikes isolated to routes using urlencoded middleware. No public exploitation by named threat actors is indicated in the provided data, so detection should focus on behavioral denial-of-service patterns rather than fixed payload signatures.

• Content-Type: application/x-www-form-urlencoded
• PayloadTooLargeError
• request entity too large
• entity.too.large
• request aborted
• ECONNRESET
• upstream timed out
• client timed out
• HTTP 413
• HTTP 429
• HTTP 499
• HTTP 502
• HTTP 503
• HTTP 504
• OOMKilled
• JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit
• body-parser

What your security team should do

• Prioritize patching internet-exposed Node.js/Express services that accept form submissions or URL-encoded API requests.
• Upgrade body-parser to 1.20.3 or later and regenerate dependency lockfiles to prevent vulnerable versions from being reintroduced.
• Inventory applications using body-parser directly or transitively, including container images, serverless packages, and monorepos.
• Apply compensating controls at the edge: body size limits, rate limiting, request timeout limits, and bot/DDoS protections for URL-encoded POST traffic.
• Limit urlencoded middleware to only the routes that require it and disable it globally where unnecessary.
• Monitor for spikes in application/x-www-form-urlencoded traffic, request parsing errors, event-loop delay, process restarts, and HTTP 502/503/504 responses.
• Add dependency scanning gates in CI/CD to block body-parser versions earlier than 1.20.3.
• Because this is not currently KEV-listed and has low EPSS, treat it as a patch-management and resilience priority rather than an emergency unless exposed services show active DoS symptoms.