CVE-2026-71324: Cross-User Response Poisoning in Traefik via HTTP/2 and HTTP/3 CONNECT Handling

Traefik is a widely deployed, open-source HTTP reverse proxy and load balancer written in Go. The software acts as an entry point for microservices, routing external traffic to internal services using various protocols. The vulnerability exists in the transition layer where incoming HTTP/2 or HTTP/3 protocols are mapped down to HTTP/1.1 connections for communication with backend servers.

Under modern HTTP specifications, specifically RFC 8441, clients can initiate a raw TCP tunnel over multiplexed HTTP/2 or HTTP/3 streams using the CONNECT method. This mechanism allows protocols like WebSockets or custom TCP-based streams to share a single, multiplexed transport channel. When Traefik processes these incoming streams, it establishes a corresponding HTTP/1.1 connection to the upstream server and forwards the headers along with the payload.

The core of the vulnerability lies in the lack of correlation between the lifecycle of the downstream tunnel stream and the upstream HTTP/1.1 connection. When the backend rejects the connection request but leaves the connection open, Traefik returns the socket to the connection pool while client-controlled bytes are still pending. This mismatch creates an attack surface where subsequent client requests get associated with smuggled data.

The root cause of CVE-2026-71324 is a desynchronization between Go's internal net/http client transport and the state of physical TCP sockets within Traefik's idle connection pool. When a client issues an HTTP/2 or HTTP/3 CONNECT request, Traefik forwards this request over an HTTP/1.1 socket managed by Go's net/http.Transport. If the backend processes the header and decides to reject the tunnel, it responds with a status code such as 401 Unauthorized or 405 Method Not Allowed.

Upon receiving this non-2xx response, the backend does not read or drain any data from the request body because it has already determined that the transaction has failed. Crucially, the backend leaves the connection open by supplying a keep-alive header. When the net/http.Transport reads the non-2xx response, it determines that the HTTP transaction is finished and returns the backend TCP socket directly to the shared idle connection pool.

However, the client's tunnel data has already been written to that same socket or is still being transmitted. Because the backend rejected the request without reading the remaining request body, those unconsumed bytes reside within the socket's receive buffer on the backend. This unconsumed payload contains complete, syntactically valid HTTP/1.1 requests drafted by the attacker. When another user's request is dispatched over this recycled connection, the backend processes the attacker's smuggled request first, leading to response poisoning.

The vulnerability has been addressed across three separate pull requests. The first patch modifies the ForwardAuth middleware to prevent tunnel data from being sent to the authentication server when the length is unknown.

// pkg/middlewares/auth/forward.go
 
	forwardBody := fa.forwardBody
	// When a CONNECT method has a body with an unknown length we consider the bytes as tunnel data.
	// Therefore, we do not want to forward them to the auth server.
	if req.Method == http.MethodConnect && req.ContentLength < 0 {
		forwardBody = false
	}
 
	if forwardBody {
		forwardReq.ContentLength = req.ContentLength
		forwardReq.TransferEncoding = req.TransferEncoding
 
		bodyBytes, err := fa.readBodyBytes(req)

The second patch targets the core proxy implementation in pkg/server/service/proxy.go. It forces the proxy to set Close = true on outgoing CONNECT requests, ensuring the underlying socket is closed after the transaction and never returned to the pool.

// pkg/server/service/proxy.go
 
			// Adding the "Connection: close" header to the request ensures that we are not reusing the connection for
			// subsequent requests in case the backend does not support CONNECT and returns a 2xx response.
			if pr.Out.Method == http.MethodConnect {
				pr.Out.Close = true
			}

The third patch introduces a new handler, connectHandler, which acts as a deferral mechanism for the payload. It blocks delivery of the CONNECT body until the upstream server explicitly returns a successful 2xx status code.

// pkg/server/service/connect.go
 
func (h *connectHandler) ServeHTTP(rw http.ResponseWriter, req *http.Request) {
	if req.Method != http.MethodConnect {
		h.next.ServeHTTP(rw, req)
		return
	}
	// ...
	pipeReader, pipeWriter := io.Pipe()
	tunnel := &connectTunnel{in: pipeWriter, data: req.Body}
	// The Transport blocks on the empty pipe, preventing the body from reaching the backend
	req.Body = pipeReader
	h.next.ServeHTTP(&connectResponseWriter{ResponseWriter: rw, req: req, tunnel: tunnel}, req)
}

In the custom connectResponseWriter, if the status code is not 2xx, the tunnel is closed and the buffered payload bytes are discarded without being written to the socket.

To exploit this vulnerability, an attacker must identify a path where Traefik handles HTTP/2 or HTTP/3 traffic and forwards it to an HTTP/1.1 backend. The target endpoint must also be configured to reject the CONNECT method or return a keep-alive non-2xx status code. The attacker then structures an HTTP/2 CONNECT request where the payload is configured to look like a standard HTTP/1.1 GET or POST request.

Because the backend processes the buffered bytes first, it generates a response to the smuggled request first. The proxy maps this response to the first available active request on the connection, which belongs to the victim client. The victim then receives the response intended for the attacker's smuggled request, potentially exposing sensitive data or executing unauthorized scripts in the context of the victim's session.

The security impact of CVE-2026-71324 is classified as high. Successful exploitation leads to cross-user response poisoning, which breaks the fundamental isolation between different clients sharing the same proxy. An attacker can manipulate what a victim receives, potentially injecting malicious JavaScript to hijack accounts or redirect traffic.

The CVSS v4.0 base score is calculated as 7.0 (High). The vulnerability does not require authentication and has low attack complexity, although it requires specific preconditions such as an upstream backend that rejects CONNECT requests while maintaining keep-alive. The primary impact is classified under subsequent confidentiality and integrity, as arbitrary responses can be forced upon unrelated sessions.

In scenarios where the ForwardAuth middleware is active with forwardBody enabled, the auth pool is also exposed. An attacker could poison the authentication connection pool, causing subsequent users' credentials or sessions to be processed against incorrect context, or potentially bypassing authentication checks entirely.

The primary recommendation is to upgrade Traefik instances to one of the patched releases: 2.11.53, 3.6.24, or 3.7.9. These updates contain the deferred body handling logic and connection closure configurations that prevent socket reuse after a rejected CONNECT transaction.

If patching is not immediately feasible, administrators can apply several mitigation strategies. Disabling HTTP/2 and HTTP/3 support on Traefik entrypoints prevents the processing of multiplexed CONNECT streams, which completely disables the primary attack vector. This can be configured by modifying the entrypoints section of the Traefik configuration file to only negotiate HTTP/1.1.

Additionally, if the ForwardAuth middleware is in use, verify that forwardBody and preserveRequestMethod are set to false. Deploying Web Application Firewall (WAF) rules to detect and drop incoming requests utilizing the CONNECT method can also prevent exploit attempts from reaching the proxy. These mitigations should be applied incrementally until a formal software upgrade is completed.