Node.js from nodejs: HTTP request desynchronization through omitted framing headers

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.

The CNA affected data identifies the following affected boundaries for vendor nodejs and product Node.js:

• Node.js 22: versions less than or equal to 22.22.3 are marked affected.
• Node.js 24: versions less than or equal to 24.16.0 are marked affected.
• Node.js 26: versions less than or equal to 26.3.0 are marked affected.

The product default status is unaffected outside the stated ranges. Red Hat VEX adds vendor-specific status for Red Hat Hardened Images: nodejs20.src and nodejs25.src are listed as known affected with no fix planned, while Red Hat packages for the Node.js 22, Node.js 24, and Node.js 26 branches are listed as fixed at specific builds. The Red Hat status must not be generalized into upstream version boundaries for every Node.js distribution.

The flaw is in the Node.js HTTP client and maps to CWE-444. It occurs when maxHeadersCount or maxHeaderPairs causes some headers to be omitted from the header collections visible to application code. The attacker-controlled input is an HTTP request with enough headers to exceed the configured limit, allowing a framing header such as Content-Length to be hidden from userland while Node.js still uses it internally for HTTP message framing. The relevant precondition is a forwarding proxy that rebuilds outbound headers from req.headers, req.rawHeaders, or req.headersDistinct while piping the original body to a reused backend connection. The proxy can therefore construct a header set that does not match the framing information Node.js used when delivering the body, creating a possible desynchronization between the proxy and backend. Network reachability is supported and authentication is not indicated as required, but exploitation depends on a deliberately crafted request and the proxy's forwarding design. The public record does not describe the lower-level implementation detail that causes the omission or provide a specific exploit payload.

The issue is remotely reachable over the network when an attacker can send an HTTP request to a matching Node.js-based forwarding proxy. The supplied assessment indicates that authentication and user interaction are not required, but exploitation has high complexity because the request must exceed the relevant header limit and reach a proxy that forwards the original body over a reused backend connection. CISA ADP records exploitation as none and automatable as no for this record. The supplied record also does not identify a public exploit. That status is time- and source-scoped and does not prove exploitation is impossible in every environment.

The primary technical outcome is inconsistent interpretation of one HTTP request by the proxy and backend because the proxy sees an incomplete header set while Node.js still processes the body using internal framing. This can produce data integrity effects or incorrect backend request handling, but the record does not define a specific payload outcome. The record provides no evidence that every deployment experiences confidentiality loss or availability loss. Actual impact depends on proxy reachability, backend connection reuse, and the application's header-rebuilding logic.

A forwarding proxy can receive a request whose visible header set is incomplete while the backend still processes the body according to Node.js's internal framing. This mismatch can cause request desynchronization and possible data integrity problems or unintended backend request handling. The practical effect depends on whether the proxy rebuilds headers, whether the backend connection is reused, and which requests can reach that path. The record does not establish data disclosure or service interruption for every Node.js deployment.

1. Upgrade each affected Node.js branch to the vendor's official fix first. The record marks a patch as available but does not provide generic upstream fixed releases, so a fix for one branch must not be assumed to cover another branch.
2. For Red Hat Hardened Images, use the fixed package builds listed by Red Hat: Node.js 22 with 22.23.2-2.3.2.hum1, Node.js 24 with 24.18.1-0.2.2.hum1, and Node.js 26 with 26.7.0-1.5.2.hum1.
3. Review the forwarding proxy design so outbound requests do not rely only on header collections that can be truncated by parser limits. Confirm that the headers used for request framing remain consistent with the body piped to the backend connection.
4. If an immediate upgrade is not possible, isolate affected forwarding paths and assess temporarily disabling the vulnerable proxy flow. This is an architecture-based risk reduction measure, not a CNA-confirmed workaround.
5. After updating, restart the processes or images containing Node.js and recheck the inventory to confirm that the runtime actually uses the fixed build.

1. Inventory services, containers, and images that use Node.js as a forwarding proxy or HTTP gateway, then compare each deployed runtime with the affected boundaries in the record.
2. Review proxy code for use of req.headers, req.rawHeaders, or req.headersDistinct to construct outbound headers, especially when the original body is piped to a reused backend connection.
3. Check the configured and effective behavior of maxHeadersCount and maxHeaderPairs, and verify that framing-critical headers are not treated as optional when the proxy creates a new request.
4. For Red Hat Hardened Images, compare deployed package identities and builds with the fixed package builds listed in the affected and remediation data.
5. In a non-production test environment, verify that the proxy and backend maintain the same request boundary interpretation when the header limit is reached. Treat generic request parsing anomalies, backend request mismatches, or unexpected connection reuse as precautionary review signals, not as confirmed indicators. Absence of log evidence does not prove safety because the record defines no specific IOC.