CVE-2026-58044

Overview

Node.js is a JavaScript runtime built on Chrome’s V8 JavaScript engine. It offers an event-driven, non-blocking I/O model that makes it lightweight and efficient, and is widely used in server-side applications.

An HTTP request smuggling vulnerability (CVE-2026-58044) has been identified in Node.js, where the HTTP parser omits headers beyond the maxHeadersCount and maxHeaderPairs limits from req.headers, req.rawHeaders, and req.headersDistinct while still using those omitted headers internally for HTTP message framing. A Content-Length header can therefore be hidden from application code while the request body is still delivered, which can desynchronize Node.js based forwarding proxies.

Per MITRE, CWE-444, Inconsistent Interpretation of HTTP Requests ("HTTP Request/Response Smuggling"), describes a product that "acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination."

The upstream advisory lists the actively supported 26.x, 24.x, and 22.x release lines as affected. The End-of-Life 12.x, 14.x, 16.x, 18.x, and 20.x lines are affected as well and received a post-EOL security fix under Node.js NES.

Details

Module Info

• Product: Node.js
• Affected packages: Node.js
• Affected versions:
  • <=26.5.0
  • <=24.18.0
  • <=22.23.1
• GitHub repository: https://github.com/nodejs/node
• Published packages: https://github.com/nodejs/node/releases
• Package manager: npm
• Fixed in: Node.js NES v12.22.20, v14.21.13, v16.20.14, v18.20.19, and v20.20.4. The 14.x, 16.x, 18.x, and 20.x NES releases shipped on August 3, 2026; the 12.x NES release shipped on August 11, 2026.

Vulnerability Info

This Low-severity vulnerability is found in the HTTP parser of the Node.js runtime itself, in every release up to and including v26.5.0, v24.18.0, and v22.23.1.

Node.js caps how many header fields it will surface to application code. The http module exposes that cap through maxHeadersCount and the parser applies a matching maxHeaderPairs limit, and the intent is that a message carrying more headers than the cap allows is handled without the extra fields reaching userland. Application code reads those headers through req.headers, req.rawHeaders, and req.headersDistinct.

The parser truncates the header set presented through those three properties, but it continues to use the omitted headers internally when it frames the HTTP message. The two views of the request therefore disagree. In particular a Content-Length header that falls past the cap is invisible to the application while the parser still uses it to read a request body off the socket.

The practical impact falls on Node.js based forwarding proxies that rebuild an outbound request from the visible IncomingMessage headers and then pipe the original body to a reused backend connection. The rebuilt headers describe a request with no body while a body is still sent, so the backend reads that body as the start of the next request on the connection. That desynchronization is the classic precondition for HTTP request smuggling: a request whose framing the front end and the back end interpret differently. Upstream scored the issue Low (CVSS v3.0 3.7), reflecting the limited integrity impact and the high attack complexity of arranging a proxy that both truncates and pipes.

Note: The flaw requires an application that reads headers from the truncated properties and forwards the original body. Servers that consume request bodies directly, rather than relaying them to a reused upstream connection, are not desynchronized by this behavior.

Mitigation

The Node.js 12.x, 14.x, 16.x, 18.x, and 20.x release lines are End-of-Life and will not receive an upstream update to address this issue. For more information see here.

Users of the affected components should apply one of the following mitigations:

• Update to a patched, actively supported Node.js release: v22.23.2, v24.18.1, or v26.5.1.
• Migrate affected applications away from the End-of-Life Node.js release lines.
• Leverage a commercial support partner like HeroDevs for post-EOL security support (Node.js NES).

Credits

• yushengchen (reporter)
• mcollina (remediation developer)