CVE-2026-58055

What it actually does

nghttp2 nghttpx through version 1.69.0 can incorrectly forward an HTTP/1.1 Upgrade request that includes both a Content-Length header and a request body to a reusable keep-alive backend connection. By reintroducing hop-by-hop Upgrade and Connection headers while preserving Content-Length, the proxy can create an ambiguous HTTP message boundary for certain backend servers. If the backend interprets the request differently from the proxy, an attacker may achieve HTTP request smuggling or response-queue poisoning, potentially causing one user's request or response stream to be confused with another's.

Why it matters to the business

Successful exploitation can allow attackers to interfere with traffic passing through an affected proxy, potentially exposing portions of other users' responses, causing users to receive attacker-influenced responses, or bypassing application-layer controls that rely on correct request parsing. The current public exploitation signal is low, with no known KEV listing, no ransomware association, low EPSS, and no reported exploit maturity, but internet-facing reverse proxies should still be prioritized because request smuggling flaws can be difficult to detect after the fact.

How an attack unfolds

An attacker sends a crafted HTTP/1.1 request to an affected nghttpx proxy. The request uses Upgrade semantics while also including a Content-Length header and a body. The proxy forwards the message to a backend over an existing keep-alive connection and preserves or re-adds headers that can influence how the backend parses the stream. If the backend treats the upgraded or body-bearing request differently than nghttpx, bytes supplied by the attacker can be interpreted as the beginning of a subsequent request. On a shared backend connection, this can desynchronize the proxy and backend, allowing the attacker to poison the response queue, cause another client to receive the wrong response, or smuggle requests past normal frontend routing and validation logic.

How to fix it

Upgrade nghttp2/nghttpx to a vendor-corrected release when available; deployments running nghttpx through 1.69.0 should be treated as potentially affected. If an exact fixed version is not yet available for the deployed package or distribution, apply vendor backports as soon as they are released. As interim mitigation, reject HTTP/1.1 Upgrade requests that contain a Content-Length header or request body unless explicitly required, disable unnecessary Upgrade/WebSocket forwarding, avoid reusing backend keep-alive connections for upgraded or ambiguous requests, and enforce strict hop-by-hop header normalization so Connection and Upgrade headers are not forwarded to backends except where intentionally supported. Where possible, place compensating controls at the edge or WAF to block Upgrade requests with nonzero Content-Length.

How to confirm the fix worked

Inventory all nghttpx deployments and confirm installed versions are newer than 1.69.0 or include a vendor backport for this issue. Review proxy configuration to ensure ambiguous Upgrade requests with Content-Length are rejected or isolated from reusable backend connections. In a controlled test environment, send an HTTP/1.1 request containing Connection: Upgrade, an Upgrade header, a nonzero Content-Length, and a body through the proxy and verify that the proxy returns an error, closes the connection, or otherwise prevents forwarding to a reusable backend connection. Confirm backend access logs do not show attacker-controlled body bytes being parsed as a separate HTTP request and that subsequent client responses are not affected.

Typical attack path

1. Identify an internet-facing service using nghttpx as a reverse proxy or gateway.
2. Confirm that HTTP/1.1 Upgrade requests are accepted and forwarded toward a backend service.
3. Send a crafted request containing Upgrade and Connection headers together with a Content-Length header and controlled body bytes.
4. Rely on inconsistent parsing between nghttpx and the backend to desynchronize the frontend/backend connection.
5. Place attacker-controlled bytes into the backend request stream so they are interpreted as a separate or subsequent request.
6. Trigger or wait for another client request to reuse the affected backend connection.
7. Observe response confusion, response-queue poisoning, or unauthorized backend behavior.

How to detect it

Review edge proxy, WAF, load balancer, and backend application logs for HTTP/1.1 requests that combine Upgrade semantics with Content-Length and a request body. Focus on requests where Connection: Upgrade, an Upgrade header, and a nonzero Content-Length appear together, especially if followed by unusual backend parsing errors, unexpected 101 Switching Protocols responses, 400-series spikes, connection resets, or responses delivered to the wrong client session. Correlate frontend request IDs with backend request logs to identify cases where a backend recorded extra requests not present at the frontend, request paths appearing inside request bodies, malformed methods immediately following Upgrade requests, or mismatched response sizes/status codes. Because exploitation may leave only protocol-level artifacts, packet captures, reverse proxy debug logs, WAF raw request logs, and backend access logs with connection identifiers are the most useful sources. There are no public reports of named threat actor exploitation, KEV inclusion, or ransomware use at this time, so detection should be behavior-based rather than signature-only.

• Connection: Upgrade
• Upgrade:
• Content-Length:
• HTTP/1.1 101 Switching Protocols
• 400 Bad Request
• client sent invalid method
• invalid request line
• upstream prematurely closed connection
• malformed HTTP request
• request header or cookie too large

What your security team should do

• Prioritize inventory of internet-facing nghttpx reverse proxies and gateways, especially versions through 1.69.0.
• Upgrade to a fixed or vendor-backported nghttp2/nghttpx package as soon as available.
• Implement temporary edge filtering for HTTP/1.1 Upgrade requests that also include Content-Length or request bodies.
• Disable unnecessary Upgrade/WebSocket support on routes that do not require it.
• Review backend keep-alive behavior and consider disabling reuse for routes handling Upgrade traffic until patched.
• Search historical proxy, WAF, and backend logs for suspicious Upgrade requests with Content-Length and anomalous response mismatches.
• Add monitoring for backend 400 errors, unexpected 101 Switching Protocols responses, and client reports of receiving incorrect content.
• Retest after remediation with a controlled smuggling probe to confirm the proxy/backend pair is no longer desynchronized.