CVE-2025-32997

What it actually does

The flaw affects applications using http-proxy-middleware with fixRequestBody in versions before 2.0.9 and 3.x before 3.0.5. If upstream Express/body-parser parsing fails, fixRequestBody can still continue processing and proxying the request body instead of stopping on the parse error. This creates inconsistent request handling between the edge application and the proxied backend: malformed, oversized, truncated, or otherwise invalid request bodies may still be forwarded after local parsing failed. The most likely impacts are validation bypass, unexpected backend behavior, request integrity issues, application errors, and limited denial-of-service conditions rather than direct remote code execution.

Why it matters to the business

Applications that rely on http-proxy-middleware to safely forward API traffic may process requests differently than expected, allowing malformed or invalid client input to reach internal services. This can cause failed transactions, incorrect backend decisions, degraded service reliability, and increased support or incident-response workload. The public exploitation signal is currently low: the CVSS score is 4.0, EPSS is approximately 0.45%, it is not in CISA KEV, and no mature public exploit is reported; however, the issue is in a widely used Node.js middleware pattern and should still be remediated during normal dependency maintenance.

How an attack unfolds

An attacker identifies an application endpoint that uses body-parser or equivalent request parsing in front of http-proxy-middleware with fixRequestBody enabled. They then send crafted HTTP requests with malformed JSON, mismatched Content-Length values, unsupported encodings, invalid charsets, truncated bodies, or oversized bodies intended to make body parsing fail. In vulnerable versions, the proxy body-fixing logic may continue despite the parser failure and forward a body to the upstream service. If the upstream service interprets the forwarded data differently from the edge application, the attacker may bypass edge-side validation or trigger unexpected backend behavior. Successful exploitation depends heavily on application-specific routing, validation, and backend logic, which is why this is assessed as lower severity and has low observed exploitation likelihood.

How to fix it

Upgrade http-proxy-middleware to a fixed release: use 2.0.9 or later for the 2.x line, or 3.0.5 or later for the 3.x line. For source-based tracking, the upstream fix is commit 1bdccbeec243850f1d2bb50ea0ff2151e725d67e. For the listed Red Hat kpatch packages, ensure kpatch-patch-3_10_0-1062_71_1 and kpatch-patch-3_10_0-1062_71_1-debuginfo are updated to 0:1-1.el7 or later where applicable. If immediate upgrade is not possible, disable or avoid fixRequestBody on routes that do not require it, ensure body-parser errors terminate request processing before proxy forwarding, enforce strict request-size limits, reject invalid Content-Type/charset combinations, and add explicit error-handling middleware before proxy middleware.

How to confirm the fix worked

Confirm dependency versions from package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, or SBOM output. Vulnerable Node.js versions are http-proxy-middleware before 2.0.9 and 3.x before 3.0.5. Verify the application no longer includes vulnerable resolved versions in production images or deployed artifacts. Functionally test representative proxied endpoints by submitting malformed JSON, unsupported charsets, incorrect Content-Length requests, and oversized payloads; the expected result after remediation is that parsing failures are rejected at the edge and are not forwarded to backend services. Review application logs to confirm body-parser errors result in 4xx responses and no corresponding backend request is generated.

Typical attack path

1. Fingerprint a Node.js/Express application or API gateway that appears to proxy requests to backend services.
2. Identify routes that accept request bodies and are likely handled by http-proxy-middleware with fixRequestBody enabled.
3. Send malformed or inconsistent HTTP request bodies designed to trigger body-parser errors, such as invalid JSON, incorrect Content-Length, unsupported charset, or oversized payloads.
4. Observe whether the edge service rejects the request or whether the backend still receives and acts on it.
5. Iterate payloads to find differences between edge validation behavior and backend processing behavior.
6. Abuse any discovered parsing inconsistency to bypass validation, trigger backend errors, or cause limited service disruption.

How to detect it

To assess possible prior exploitation, correlate edge application logs, reverse-proxy logs, API gateway logs, backend service logs, and application error telemetry. Look for requests where body-parser or Express reported parse failures but a corresponding proxied backend request still occurred. Useful evidence includes repeated malformed JSON errors, mismatched Content-Length errors, unsupported charset or encoding errors, oversized body errors, and 4xx parse failures at the edge paired with 2xx/3xx/5xx responses from an upstream service on the same route, timestamp, client IP, trace ID, or request ID. Review WAF and access logs for bursts of POST, PUT, PATCH, or DELETE requests containing invalid JSON, unusual Content-Type headers, nonstandard charsets, chunked transfer anomalies, or payload sizes near configured limits. In Node.js telemetry, inspect stack traces or error logs mentioning body-parser failures around routes configured with http-proxy-middleware and fixRequestBody. There are no known public attacker-specific indicators for this CVE, so detection should focus on behavioral signs of parser/proxy inconsistency rather than fixed malicious infrastructure.

• http-proxy-middleware
• fixRequestBody
• entity.parse.failed
• request.size.invalid
• entity.too.large
• encoding.unsupported
• charset.unsupported
• request.aborted
• SyntaxError: Unexpected token
• PayloadTooLargeError: request entity too large
• Error: request size did not match content length
• unsupported charset
• invalid json
• malformed JSON
• Content-Length

What your security team should do

• Inventory applications, containers, serverless packages, and build artifacts that include http-proxy-middleware.
• Prioritize internet-facing API gateways, BFF services, developer portals, and reverse-proxy services that accept request bodies and use fixRequestBody.
• Upgrade to http-proxy-middleware 2.0.9 or later, or 3.0.5 or later, and rebuild/redeploy affected applications.
• Add regression tests ensuring body-parser failures stop request processing and are not forwarded to upstream services.
• Harden API gateway controls with strict Content-Type validation, request-size limits, charset allowlists, and consistent error handling.
• Search recent logs for repeated body-parser failures followed by successful backend activity on the same route or request correlation ID.
• Because this issue is not KEV-listed, has low EPSS, and has no reported mature exploit, treat it as routine but timely patching unless affected services are internet-facing or protect sensitive backend functions.