CVE-2026-58044 is a low-severity Node.js HTTP vulnerability fixed in the July 29, 2026 security releases. Node could truncate certain header values, creating request-smuggling risk when an application forwards those altered headers to another HTTP server.

The vulnerable behavior becomes important at a protocol boundary: Node parses an inbound request, application code copies headers, and an upstream or downstream server interprets the forwarded request differently.

Quick answer

Update Node.js 22, 24, or 26 to 22.23.2, 24.18.1, or 26.5.1. Audit reverse proxies and gateway code that forwards inbound headers. Construct the outbound request from an explicit allowlist and reject ambiguous framing instead of copying every header.

const forwardedHeaders = {
  "content-type": req.headers["content-type"] ?? "application/octet-stream",
  "x-request-id": validatedRequestId(req.headers["x-request-id"]),
};

// Do not forward inbound content-length, transfer-encoding,
// connection, or hop-by-hop headers unchanged.

Let the HTTP client calculate message framing from the actual body whenever possible.

Why parser disagreement causes smuggling

HTTP request smuggling occurs when two components disagree about where one request ends and another begins. An attacker crafts input interpreted one way by the first component and another way by the next component.

Header truncation can contribute to that disagreement if the Node layer validates or forwards a different value from what another server effectively receives. The risk is not limited to a public reverse proxy product. Custom API gateways, webhook relays, server-side rendering proxies, and development middleware can all forward requests.

Find forwarding code

Search for raw use of incoming headers in outbound requests.

rg -n "req\\.headers|request\\.headers|headers:\\s*\\{|http\\.request|https\\.request|fetch\\(" src

Look for:

  • { ...req.headers };
  • loops copying every header;
  • manual content-length calculations;
  • forwarding both content-length and transfer-encoding;
  • raw socket or custom proxy code;
  • trust in connection header tokens;
  • multiple proxy layers with different HTTP versions.

Framework proxy packages should also be inventoried and updated, but the Node runtime patch is still required.

Build outbound headers deliberately

Define the few headers the upstream service needs. Generate authentication, host, tracing, and framing values on the trusted side.

Remove hop-by-hop headers described by HTTP semantics, including connection and the headers it names. Do not forward a client’s host when routing is controlled by server configuration.

For a streamed body, use a maintained client or proxy library that owns framing. If manual forwarding is unavoidable, document whether the connection to each hop uses HTTP/1.1 or HTTP/2 because the framing rules differ.

Test without attacking production

Use an isolated chain containing the same Node gateway and a small recording upstream. Send malformed and edge-case requests from a controlled test client and verify both components agree on the number of requests, headers, and body boundaries.

Cover:

  • duplicate framing headers;
  • conflicting content length;
  • transfer encoding tokens;
  • oversized and unusual header values;
  • connection-specific headers;
  • keep-alive with two sequential requests.

Do not publish or run destructive payloads against systems you do not own. The objective is to ensure invalid requests are rejected consistently, not to demonstrate access to another user’s response.

Patch and verify each hop

Upgrade the Node runtime in the gateway and any Node-based upstream that parses forwarded traffic. Rebuild containers and inspect the running version.

Then check the load balancer, CDN, service mesh, and upstream server versions. A patched Node layer reduces this specific flaw but request-smuggling resistance depends on consistent parsing across the chain.

Monitor 400 responses, upstream connection resets, mismatched request IDs, unusual keep-alive behavior, and proxy parsing warnings during canary rollout.

Keep severity in context

The advisory rates this Node flaw low severity, but local architecture affects practical impact. A service that never forwards request headers has a different exposure from an internet gateway that copies them into a long-lived upstream HTTP/1.1 connection.

Patch supported runtimes regardless, then spend deeper review time where parser boundaries and header forwarding exist.

Primary sources

The durable design is simple to state: patch the parser, forward only intentional headers, let one component own body framing, and test the complete proxy chain for agreement.

Keep that chain test whenever a CDN, proxy, mesh, or upstream server changes.