CVE-2026-56866: HTTP/1 client connection desynchronization after CONNECT rejection in net/http
When http.Transport sends an HTTP/1 CONNECT request with a non-empty Request.Body, it writes the body directly to the connection without framing after the request headers. If the server rejects the CONNECT request with a non-2xx keep-alive response, Transport returns the connection to the idle pool. Because CONNECT requests do not have a request body, the server may interpret the trailing body bytes as a subsequent pipelined HTTP/1.1 request on the connection, leaving the pooled connection desynchronized and causing the next caller that reuses it to read the response to the injected request. In reverse proxies (including httputil.ReverseProxy) that forward CONNECT requests through a shared Transport, this can lead to cross-user response poisoning.
Affected Software
Event History
Frequently Asked Questions
Which deployments are most exposed to cross-user impact?
Reverse proxies, including httputil.ReverseProxy, are exposed when they forward CONNECT requests through a shared http.Transport. Reuse of the desynchronized idle connection can cause a later caller to receive the response associated with an injected request.
What conditions are required to trigger the connection desynchronization?
The Transport must send an HTTP/1 CONNECT request with a non-empty Request.Body, and the server must reject the CONNECT request with a non-2xx response while keeping the connection alive. The connection is then returned to the idle pool despite the trailing body bytes.