Node.js HTTP client header truncation enables request smuggling in forwarding proxies

A flaw in Node.js HTTP client can cause a request desynchronization for Node.js-based forwarding proxies that rebuild outbound headers from the visible IncomingMessage headers while piping the original body to a reused backend connection.

Node.js can omit headers beyond maxHeadersCount / maxHeaderPairs from req.headers, req.rawHeaders, and req.headersDistinct, while still using those omitted headers internally for HTTP message framing. In particular, Content-Length can be hidden from userland while the request body is still delivered.

This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.

• Node.js 26: versions through and including 26.5.0 are recorded as affected. The corresponding fixed release is 26.5.1.
• Node.js 24: versions through and including 24.18.0 are recorded as affected. The corresponding fixed release is 24.18.1.
• Node.js 22: versions through and including 22.23.1 are recorded as affected. The corresponding fixed release is 22.23.2.

The CNA record sets the default status to unaffected outside the listed affected entries. The Node.js advisory confirms exposure across all three active release lines listed above.

The flaw is in Node.js HTTP client header handling and is classified as CWE-444 HTTP Request Smuggling. When a request exceeds maxHeadersCount or maxHeaderPairs, Node.js can omit headers from req.headers, req.rawHeaders, and req.headersDistinct while still using those headers internally for HTTP message framing. As a result, Content-Length can be absent from the userland view even though the request body is still delivered. The dangerous condition occurs when a forwarding proxy rebuilds outbound headers from the visible headers and pipes the original body to a reused backend connection. Under that design, the proxy and backend may interpret request boundaries differently. The available evidence does not identify the exact parser branch or payload required to trigger the condition.

The issue is network reachable and the record indicates that it does not require authentication or user interaction. Attack complexity is high because exploitation depends on a forwarding proxy that rebuilds headers from IncomingMessage while forwarding the body over a reused backend connection. The supplied record marks public_exploit as false and known_exploited as null. The available evidence therefore does not confirm a public exploit or observed exploitation, and the record's silence should not be treated as proof that exploitation has never occurred.

• A remote client may influence how a forwarding proxy and backend interpret a request when the proxy uses truncated visible headers to rebuild the request while forwarding the original body.
• The technical result may be request desynchronization or request smuggling on a reused backend connection.
• The record indicates that exploitation does not require authentication or user interaction, but complexity is high and the outcome depends on the proxy architecture.
• The supported primary consequence is an integrity impact on forwarded requests. No evidence confirms data disclosure, privilege gain, service disruption, or a change in security scope.

The flaw can cause a forwarding proxy and backend to interpret the boundaries or contents of a forwarded request differently. This may alter the integrity of requests reaching downstream services and affect request processing, routing, or validation. The evidence does not establish a specific data modification, disclosure, service outage, victim, or breach. Exposure depends substantially on whether the organization uses Node.js as a forwarding proxy with backend connection reuse and header reconstruction.

1. Upgrade Node.js 26 to 26.5.1, Node.js 24 to 24.18.1, or Node.js 22 to 22.23.2, according to the release branch in use. These upstream releases include the related http: reject requests exceeding max header count change.
2. Redeploy or restart processes, containers, and workers so they actually load the fixed runtime rather than only receiving updated files on disk.
3. Reassess forwarding proxy code after the upgrade, particularly code that rebuilds headers from IncomingMessage while piping the body to a reused backend connection.
4. If an upgrade cannot be completed immediately, reduce exposure by stopping or isolating the affected proxy path where operationally feasible. The supplied evidence does not provide a Node.js-confirmed workaround, so this should be treated as temporary risk reduction rather than a fix.

• Inventory processes and containers running Node.js, then compare their runtime versions with the fixed releases listed in remediation.
• Identify Node.js-based forwarding proxies that construct outbound headers from req.headers, req.rawHeaders, or req.headersDistinct while directly piping the request body.
• Review use or configuration of maxHeadersCount and maxHeaderPairs, especially on endpoints that accept requests from untrusted networks.
• Inspect handling of Content-Length and other message-framing headers to ensure the proxy does not derive framing only from the userland-visible header set.
• If telemetry records request desynchronization, backend connection reuse, or inconsistent request boundaries, use it as a lead for investigation rather than as a Node.js-confirmed IOC. Absence of matching logs does not prove that a system is safe.