CVE-2026-55603: http-proxy-middleware Multipart CR/LF Injection Vulnerability

Technical summary

The vulnerability exists in the handlerFormDataBodyData() function, which is called by fixRequestBody() to reconstruct multipart/form-data bodies. The function directly interpolates form field keys and values from req.body into the multipart wire format without sanitizing or encoding CR/LF characters (\x0d\x0a). Because multipart boundaries are delimited by CRLF sequences, an attacker-controlled value containing \r\n can prematurely terminate the current part boundary and inject malformed or entirely new parts that follow. This results in a request/parameter desynchronization vulnerability (CWE-93): the gateway-side policy engine evaluates the req.body object before proxy reconstruction, while the upstream backend parses the reconstructed wire format and encounters injected fields. The affected versions are 3.0.4 through 3.0.7 and 4.1.1; the fix is available in 3.0.7 and 4.1.1 or later.

Business impact

Organizations using http-proxy-middleware in API gateways, reverse proxies, or request routing pipelines face two critical risks. First, security controls that validate or filter req.body fields (rate limiting, input validation, access control policies) are bypassed because they evaluate the legitimate form fields while the backend receives injected parameters. Second, attackers can inject fields that execute unintended actions—such as privilege escalation, unauthorized data access, or business logic manipulation—if the upstream service trusts proxy-provided parameters. In multi-tenant environments or when the proxy sits between untrusted clients and sensitive backend services, this can lead to cross-customer data leakage or unauthorized actions performed as legitimate users.

Affected systems

The vulnerability affects chimurai's http-proxy-middleware versions 3.0.4 through 3.0.7 (inclusive) and version 4.1.1. Any Node.js application that uses fixRequestBody() to handle multipart/form-data requests is at risk. This includes API gateways, reverse proxies, microservice routers, and authentication/authorization proxies that rewrite or re-emit request bodies. Applications that do not use fixRequestBody(), or that do not proxy multipart/form-data requests, are not affected. Check your package-lock.json or package.json to determine if a vulnerable version is in use.

Exploitability

The CVSS 3.1 score of 7.5 (HIGH) reflects moderate attack complexity but high impact. Exploitation requires network access and crafted multipart form submissions but no authentication or user interaction. The attacker must know or guess valid form field names expected by the backend to inject additional parameters effectively. Attack complexity is rated as high because the attacker must understand the downstream service's form schema and parameters; however, this information is often publicly documented or discoverable. Once an attacker understands the target service, exploitation is straightforward: inject CR/LF characters into form field values and observe whether injected fields are processed by the backend.

Remediation

Upgrade http-proxy-middleware to version 3.0.7 or later (for the 3.x line) or version 4.1.1 or later (for the 4.x line). These versions properly escape CR/LF characters in multipart form field values, preventing boundary injection. Test the upgrade in a staging environment to ensure no breaking changes affect your request routing. If you cannot upgrade immediately, consider disabling fixRequestBody() and instead letting the original request flow through, or implement manual CR/LF sanitization before reconstructing multipart bodies. For highest security, validate and canonicalize form field names and values at the proxy layer before they reach downstream services.

Patch guidance

Verify the fixed versions against the vendor advisory for http-proxy-middleware. The patches were released to address CR/LF sanitization in multipart/form-data reconstruction. When patching, test proxy behavior with legitimate multipart requests (file uploads, standard form submissions) to ensure the sanitization does not corrupt valid payloads. If your application builds custom body reconstruction logic on top of or alongside fixRequestBody(), review that code for similar CR/LF handling issues. Automated dependency scanning tools should be configured to flag versions 3.0.4–3.0.7 and 4.1.1 as vulnerable.

Detection guidance

Monitor proxy logs and upstream access logs for multipart requests with suspicious field names or values containing encoded or literal CR/LF sequences (\r, \n, %0d, %0a). Watch for form field counts or field names in proxy logs that differ from those in backend logs—a sign that field injection succeeded. Implement request body inspection at the proxy layer to detect and reject multipart parts with boundary-delimiter characters in field values. If feasible, correlate the form fields validated by your proxy middleware against the fields actually processed by the backend; significant divergence suggests successful exploitation. Web application firewalls should inspect multipart bodies for CR/LF injection patterns.

Why prioritize this

This vulnerability ranks as HIGH priority because it enables request/parameter desynchronization attacks that bypass gateway-level validation and access control policies. Unlike many proxy vulnerabilities that require specific configurations, fixRequestBody() with multipart data is a documented and commonly-used feature. The attack surface is large: any public-facing proxy handling form submissions or file uploads is potentially vulnerable. Patch deployment should be expedited for internet-facing services and those handling sensitive data or authentication.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects a network-accessible vulnerability with high integrity impact (parameter injection leading to unintended actions) and low confidentiality impact (information disclosure via field injection). Attack complexity is high because successful exploitation requires understanding the downstream service's expected parameters. Scope is changed because the impact extends beyond the proxy itself to the upstream service. The absence of a known exploit in the wild (KEV status is false) slightly reduces near-term urgency but should not delay patching, as the vulnerability is straightforward to weaponize.

Frequently asked questions