CVE-2026-58044

What it actually does

This flaw affects Node.js-based HTTP forwarding proxies that reconstruct outbound headers from the user-visible IncomingMessage header collections while streaming the original request body to a reused backend connection. Node.js may omit headers that exceed maxHeadersCount or maxHeaderPairs from req.headers, req.rawHeaders, and req.headersDistinct, but still honor omitted headers internally for HTTP message framing. If an omitted header such as Content-Length controls the presence or size of a body, proxy code may forward a request that appears headerless or bodyless to application logic while still sending the original body on a persistent backend connection. Under the right proxy/backend behavior, this can create HTTP request desynchronization and enable limited request smuggling or backend request confusion. The assigned severity is low because exploitation is configuration- and implementation-dependent, requires a proxy pattern that rebuilds headers incorrectly, and has limited direct impact.

Why it matters to the business

Organizations using Node.js 22, 24, or 26 to build custom HTTP forwarding proxies, API gateways, reverse proxies, or middleware may be exposed to backend request confusion that can alter how downstream services interpret traffic. Practical consequences can include bypassing routing or access-control assumptions enforced at the proxy layer, corrupting request streams on reused connections, triggering unexpected backend behavior, or enabling targeted manipulation of another request on the same connection. The issue is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, so it is lower urgency than actively exploited edge-device flaws; however, it should still be addressed promptly in internet-facing proxy components because request desynchronization flaws can be difficult to detect and may affect high-value application traffic.

How an attack unfolds

An attacker sends a specially crafted HTTP request to a Node.js-based forwarding proxy with enough headers to exceed the configured header count or header-pair limit. The attacker positions a framing-relevant header, especially Content-Length, beyond the point where Node.js exposes headers to userland. The proxy application then rebuilds outbound headers from req.headers, req.rawHeaders, or req.headersDistinct and therefore does not include the hidden Content-Length value. At the same time, Node.js still uses the omitted Content-Length internally and delivers the request body. If the proxy pipes that original body to a reused backend connection, the backend can receive bytes that the proxy did not intend to associate with the forwarded request. Depending on backend parsing, connection reuse, and request sequencing, those bytes may be interpreted as part of the current request or as the beginning of a subsequent request, causing desynchronization. A successful attack requires careful alignment of header limits, body length, keep-alive behavior, and backend request parsing, which is why exploitation complexity is high.

How to fix it

Upgrade Node.js to a vendor-fixed release for the affected supported lines as soon as patched versions are available from the official Node.js project or operating-system/package distributor. The provided input does not include exact fixed versions, so track the Node.js security release notes for Node.js 22, 24, and 26 and update all runtime images, base containers, server packages, and bundled runtimes accordingly. As a defense-in-depth mitigation, avoid implementing forwarding proxies that rebuild outbound headers from user-visible IncomingMessage collections while piping the original body unchanged. Ensure proxy code treats excessive-header requests as invalid and rejects them before forwarding, especially when Content-Length, Transfer-Encoding, Host, Connection, or other framing/routing headers may be omitted from userland views. Disable or limit backend connection reuse for affected proxy paths if immediate patching is not possible. Enforce strict request normalization at a hardened edge proxy before traffic reaches Node.js, including maximum header count, maximum header size, duplicate header policy, and explicit rejection of ambiguous Content-Length or Transfer-Encoding combinations. Do not trust req.headers alone to make security-sensitive forwarding decisions when operating near header-count limits.

How to confirm the fix worked

Confirm all deployed Node.js runtimes in the affected major lines have been upgraded to a fixed vendor release once available. Validate container images and server packages by checking `node --version`, package manager metadata, SBOMs, and base image rebuild dates. Review custom proxy code for patterns that copy or reconstruct headers from `req.headers`, `req.rawHeaders`, or `req.headersDistinct` while streaming `req` or the original request body directly to an outbound request. In a controlled test environment, send requests with header counts above configured maxHeadersCount or maxHeaderPairs and place Content-Length after the cutoff; verify the proxy rejects the request or forwards a fully consistent, normalized request without desynchronizing the backend connection. Confirm backend access logs, proxy logs, and packet captures agree on request boundaries, body length, and response mapping. Also verify keep-alive connection reuse does not allow bytes from one client request to affect another backend request.

Typical attack path

1. Identify a Node.js-based forwarding proxy, API gateway, reverse proxy, or middleware service that accepts external HTTP requests and forwards them to a backend over persistent connections.
2. Send reconnaissance requests with unusually large numbers of headers to determine whether the service enforces or inherits maxHeadersCount or maxHeaderPairs behavior.
3. Craft a request where benign visible headers appear before the header limit and a framing-relevant header such as Content-Length appears after the visible-header cutoff.
4. Include a body whose bytes are still delivered by Node.js even though the proxy code does not see or forward the controlling Content-Length header.
5. Rely on the proxy to rebuild outbound headers from req.headers, req.rawHeaders, or req.headersDistinct while piping the original body to a reused backend connection.
6. Cause the backend connection to become desynchronized so that body bytes are interpreted differently by the backend than by the proxy.
7. Use the confusion to influence backend routing, request boundaries, or subsequent requests, subject to the behavior of the specific proxy and backend stack.

How to detect it

Look for evidence of crafted HTTP requests with unusually high header counts, especially where Content-Length, Transfer-Encoding, Host, Connection, or other framing-sensitive headers appear late in the request or are duplicated. Useful sources include edge proxy logs, Node.js application logs, WAF logs, load balancer logs, backend application access logs, HTTP error logs, and packet captures from proxy-to-backend connections. Investigate spikes in 400, 408, 413, 431, 502, or 503 responses, backend parser errors, connection resets, mismatched request IDs between proxy and backend, unexpected bodies on routes that normally do not accept bodies, and responses delivered to the wrong client/request context. Compare front-end and backend logs for the same time window: exploitation often leaves inconsistencies where the proxy records one request while the backend records an extra, malformed, truncated, or differently routed request on the same keep-alive connection. If verbose Node.js logging is available, review events around header-count limit handling and request abortion. There are no known named threat actors or public exploitation campaigns in the provided data, so detection should focus on behavioral artifacts rather than actor-specific infrastructure.

• HTTP requests with header counts exceeding maxHeadersCount
• HTTP requests with header counts exceeding maxHeaderPairs
• Content-Length header appearing after an unusually large number of preceding headers
• Transfer-Encoding header appearing after an unusually large number of preceding headers
• duplicate Content-Length
• Content-Length and Transfer-Encoding in the same request
• HTTP 431 Request Header Fields Too Large
• HPE_HEADER_OVERFLOW
• Parse Error: Header overflow
• client sent too many header lines
• upstream prematurely closed connection
• socket hang up
• ECONNRESET
• ERR_HTTP_HEADERS_SENT
• unexpected body on request
• request desynchronization
• HTTP request smuggling

What your security team should do

• Inventory all services running Node.js 22, 24, or 26, prioritizing internet-facing forwarding proxies, API gateways, reverse proxies, SSRF brokers, webhook relays, and middleware that forwards raw request bodies.
• Track Node.js security advisories and apply the fixed releases for each affected release line as soon as they are published by the runtime or OS/package vendor.
• Search codebases for forwarding patterns that rebuild headers from `req.headers`, `req.rawHeaders`, or `req.headersDistinct` and pipe the original request body to an outbound backend connection; remediate these patterns even after runtime patching.
• Add or tighten edge controls that reject requests with excessive header counts, ambiguous message framing, duplicate Content-Length, conflicting Content-Length and Transfer-Encoding, or unexpected bodies on methods/routes that should not have bodies.
• Temporarily disable backend keep-alive or isolate backend connections per client/request for high-risk proxy paths if patching is delayed and the architecture is susceptible.
• Increase logging around rejected malformed requests, high header counts, backend connection errors, unexpected 400/502 responses, and request/response mismatches.
• Because this issue is not currently KEV-listed, not associated with ransomware in the provided data, and has low EPSS, prioritize it after actively exploited internet-facing vulnerabilities but before routine backlog items affecting externally reachable proxy services.