CVE-2026-55603

What it actually does

http-proxy-middleware's fixRequestBody() rebuilds a consumed multipart/form-data body by interpolating each parsed req.body key and value into the MIME wire format without neutralizing CR/LF. A line break in a field name or value can terminate the current part and append extra parts. The proxy still sees one opaque value, so gateway validation runs on a different field set than the upstream parser, causing request/parameter desynchronization across the trust boundary (integrity-heavy, limited confidentiality, no availability impact; high attack complexity).

Why it matters to the business

Gateway or BFF checks on uploads and forms can be bypassed so backends honor extra parameters the edge never approved, risking unauthorized state changes and policy bypass. Not in CISA KEV, no ransomware use, exploit maturity none, EPSS ~0.0029 and flat over 30 days, so mass exploitation is unlikely; still patch Node.js proxy layers using chimurai http-proxy-middleware because CVSS 7.5 with changed scope and high integrity impact, and the package is common in API-gateway patterns. The CVE has been public for about 106 days.

How an attack unfolds

An unauthenticated remote attacker targets an app that calls the documented fixRequestBody() helper on multipart/form-data after a body parser has consumed the stream. They submit a multipart request whose field name or value includes CR/LF so that, when the helper rebuilds the body, the current MIME part ends and extra parts are introduced. Edge policies evaluate the original parsed object and allow the request; the reconstructed body forwarded upstream contains additional parts the backend treats as distinct parameters, enabling parameter injection or control bypass. No public exploit code or named threat-actor campaigns are associated with this issue.

How to fix it

Upgrade chimurai http-proxy-middleware to 3.0.7 (3.x) or 4.1.1 (4.x). Inventory package.json, lockfiles, and container images for 3.0.4–3.0.6 and 4.x before 4.1.1 (the issue starts at 3.0.4). Prefer not calling fixRequestBody() on multipart bodies until patched; if you must rebuild, do not interpolate untrusted keys/values into MIME without neutralizing CR/LF, and keep edge validation aligned with what the upstream parser will see. Rebuild and redeploy all services that bundle the library.

How to confirm the fix worked

Confirm resolved versions 3.0.7 or 4.1.1 (or later) in lockfiles and deployed images (npm ls http-proxy-middleware). Search code for fixRequestBody() on multipart/form-data routes. After upgrade, send a harmless multipart request with embedded line breaks in a field and confirm the upstream receives the same field set the gateway parsed, with no extra parts. Review proxy/debug logs for reconstructed bodies that gained parts the client did not send.

Typical attack path

1. Locate a Node.js service that uses http-proxy-middleware and re-emits multipart/form-data via fixRequestBody() after parsing.
2. Send a multipart request in which a form field name or value contains CR/LF so reconstruction can close the current part and add others.
3. Rely on gateway/WAF/validation seeing only the original parsed fields and allowing the request.
4. Let the rebuilt body reach the upstream parser, which interprets the extra parts as additional parameters.
5. Use those extra parameters to alter backend behavior relative to what the edge approved.

How to detect it

There is no public exploit, KEV listing, or named campaign, so confirmed in-the-wild use is unlikely; hunt for evidence of parameter desync rather than a single payload. Compare gateway/access logs of parsed multipart field names and counts with upstream application logs for the same request IDs. Inspect proxy debug or body-rebuild logs around fixRequestBody() for reconstructed multipart bodies that contain more parts or Content-Disposition headers than the client sent. Review Node.js error and application logs for unexpected extra form fields on upload or form endpoints after a proxy hop. Check package-lock/npm ls history and image layers for 3.0.4–3.0.6 or 4.x before 4.1.1 during the window of exposure. Network captures of proxied multipart traffic that show additional parts after reconstruction are the strongest forensic artifact.

What your security team should do

• Patch http-proxy-middleware to 3.0.7 or 4.1.1 in every service that proxies multipart traffic; treat internet-facing BFFs and API gateways first.
• Inventory lockfiles and images for 3.0.4–3.0.6 and unpatched 4.x even if EPSS is low and the CVE is not in KEV.
• Until patched, avoid fixRequestBody() for multipart/form-data or stop re-parsing rebuilt bodies with a different field set than the edge.
• Align gateway validation with upstream parsers so extra MIME parts cannot bypass policy.
• Watch Node.js proxy and body-parser logs for field-count or field-name mismatches on multipart requests; no named actors or public exploits are known.