CVE-2025-13466

What it actually does

body-parser 2.2.0 inefficiently processes URL-encoded request bodies that contain a very large number of parameters, even when the overall request body remains within the default 100KB size limit. A remote, unauthenticated attacker can repeatedly submit parameter-dense application/x-www-form-urlencoded POST requests to endpoints that use body-parser's urlencoded parsing path, causing disproportionate CPU consumption, memory pressure, event-loop delay, increased request latency, and potential partial denial of service. The issue affects availability only; it does not directly enable code execution, data theft, authentication bypass, or data modification.

Why it matters to the business

Applications and management services that parse URL-encoded HTTP requests with affected body-parser versions may become slow or intermittently unavailable under sustained malicious traffic. For SUSE Manager Server Module 4.0 and SUSE Manager Proxy Module 4.0 deployments, this can affect administrative workflows, software management, patch orchestration, proxy operations, and monitoring-related services if exposed components process such requests. The vulnerability is not currently in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no reported mature public exploit, but it has been public for 258 days, so internet-facing or high-dependence services should still be remediated during normal patch cycles or sooner where availability is critical.

How an attack unfolds

An attacker first identifies an HTTP endpoint backed by an affected application stack using body-parser 2.2.0 and accepting URL-encoded form submissions. The attacker then sends repeated POST requests with Content-Type set to application/x-www-form-urlencoded and a body containing thousands of distinct parameters packed into a relatively small request body. Because the parser spends excessive resources enumerating and handling the parameter set, each request consumes more CPU and memory than expected. By sustaining concurrent requests, the attacker can tie up worker processes or the Node.js event loop, causing slow responses, timeouts, elevated error rates, and degraded service for legitimate users. Exploitation does not require authentication, user interaction, or network adjacency when the vulnerable endpoint is reachable over the network.

How to fix it

Upgrade body-parser from 2.2.0 to 2.2.1 or later wherever it is used directly or transitively. For SUSE Manager Proxy Module 4.0 and SUSE Manager Server Module 4.0, apply vendor updates at or above the fixed package versions provided: mgr-osad 4.0.11-3.9.2; patterns-suse-manager 4.0-9.10.2; spacecmd 4.0.18-3.13.2; spacewalk-backend 4.0.30-3.23.3; spacewalk-certs-tools 4.0.15-3.15.2; spacewalk-client-tools 4.0.12-3.13.2; spacewalk-web 4.0.19-3.18.3; supportutils-plugin-susemanager-client 4.0.3-3.3.2; supportutils-plugin-susemanager-proxy 4.0.3-3.3.2; branch-network-formula 0.1.1580471316.1839544-3.10.2; image-sync-formula 0.1.1579102150.4716559-3.11.2; prometheus-formula 0.1-4.7.2; pxe-formula 0.1.1580384994.6076a7e-3.11.2; py26-compat-salt 2016.11.10-10.11.2; python-susemanager-retail 1.0.1580471316.1839544-3.13.2; spacewalk-java 4.0.31-3.23.1; spacewalk-utils 4.0.16-3.15.2; susemanager 4.0.22-3.20.3; susemanager-doc-indexes 4.0-10.18.2; and susemanager-docs_en 4.0-10.18.2. Where immediate patching is not possible, reduce exposure by placing affected services behind authentication and rate limiting, limiting request body size, enforcing strict parameter-count limits at the reverse proxy or application layer, rejecting abnormal URL-encoded submissions, tuning WAF rules for excessive parameter counts, and monitoring resource saturation. These mitigations reduce risk but should not replace upgrading to the fixed parser or vendor packages.

How to confirm the fix worked

Confirm dependency remediation by checking package manifests, lockfiles, software composition analysis results, container images, and runtime dependency trees for body-parser 2.2.1 or later and absence of body-parser 2.2.0. On SUSE-managed systems, verify installed package versions with the platform package manager and confirm they meet or exceed the fixed versions listed by the vendor. Validate runtime behavior in a controlled test environment by submitting high-parameter-count URL-encoded requests and confirming the application rejects or handles them without abnormal CPU spikes, memory growth, event-loop delay, increased latency, or worker exhaustion. Also verify that reverse proxies, WAFs, and application gateways enforce body-size, parameter-count, and request-rate limits as intended.

Typical attack path

1. Discover an exposed web application or management interface that accepts URL-encoded form submissions.
2. Confirm that reachable endpoints process application/x-www-form-urlencoded request bodies.
3. Send crafted POST requests containing thousands of URL-encoded parameters while keeping the request body near or below common size limits such as 100KB.
4. Increase request concurrency or repetition to amplify CPU usage, memory pressure, and event-loop latency.
5. Maintain sustained traffic until the service slows down, returns 5xx/timeout responses, or becomes partially unavailable.

How to detect it

To assess prior exploitation, review reverse proxy, load balancer, WAF, CDN, web server, and application logs for bursts of POST requests using application/x-www-form-urlencoded with unusually high numbers of parameters, large query-style bodies near configured size limits, repeated requests to the same form endpoints, abnormal request durations, 413/400/429/500/502/503/504 responses, client disconnects, and timeout errors. Correlate these events with host and application telemetry showing elevated CPU, memory pressure, garbage collection activity, Node.js event-loop delay, worker restarts, container restarts, autoscaling events, or process out-of-memory kills. In Node.js/Express logs, search for parser-related errors such as too many parameters or request entity parsing failures around the same time as latency spikes. Because this denial-of-service pattern does not create a unique file artifact, detection should rely on traffic shape, request concentration by source IP or autonomous system, parser error messages, and resource-exhaustion telemetry rather than a single definitive IOC.

• body-parser@2.2.0
• "body-parser": "2.2.0"
• body-parser/2.2.0
• Content-Type: application/x-www-form-urlencoded
• application/x-www-form-urlencoded
• parameters.too.many
• too many parameters
• PayloadTooLargeError
• request entity too large
• entity.too.large
• 413 Payload Too Large
• upstream timed out
• client intended to send too large body
• JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit
• ENOMEM
• ETIMEDOUT

What your security team should do

• Inventory internet-facing and internally critical Node.js, Express, and SUSE Manager-related services that parse application/x-www-form-urlencoded request bodies.
• Prioritize patching exposed or availability-critical services to body-parser 2.2.1 or later, or to the fixed SUSE package versions where applicable.
• Add or confirm compensating controls: per-IP rate limits, request body limits, parameter-count limits, WAF rules for excessive form parameters, and upstream timeout controls.
• Monitor application performance telemetry for CPU spikes, memory pressure, event-loop lag, request queue growth, and surges in POST request volume to form-handling endpoints.
• Review web access logs and application logs for repeated URL-encoded POST requests with unusually high parameter counts, especially from a small set of source IPs.
• Include this vulnerability in dependency scanning and CI/CD policy checks so body-parser 2.2.0 is blocked from redeployment.
• Treat confirmed exploitation primarily as an availability incident: preserve logs, identify source infrastructure, apply temporary blocks or rate limits, and verify service recovery after mitigation.