V2: Traefik: Cross-user response poisoning via proxied CONNECT on Traefik's shared backend keep-alive pool (CVE-2026-71324)
## Summary There is a critical vulnerability in Traefik's default HTTP reverse proxy that leads to unauthenticated cross-user response poisoning. When a client opens an HTTP/2 or HTTP/3 `CONNECT` request, Traefik forwards it — body included — to an HTTP/1.1 upstream over a shared `net/http.Transport`. If the upstream answers the CONNECT with a keep-alive non-2xx response without draining the body, the now-desynchronized backend socket is returned to Traefik's shared connection pool and reused for other clients, letting an attacker make a different client read a response the attacker smuggled — which may be another user's authenticated or private content. The entrypoint's `sanitizePath` option (default `true`) is not a reliable defense: backends that answer `CONNECT /` with a keep-alive non-2xx remain exploitable. The experimental FastProxy implementation was not affected. The issue is fixed by deferring the forwarded CONNECT payload until the backend accepts the tunnel, by not returning CONNECT connections to the shared idle pool, and by discarding the CONNECT body in the ForwardAuth path. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.53 - https://github.com/traefik/traefik/releases/tag/v3.6.24 - https://github.com/traefik/traefik/releases/tag/v3.7.9 ## For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> ## Summary Traefik's default reverse proxy forwards a plain HTTP/2 or HTTP/3 `CONNECT` request and its body to an HTTP/1.1 upstream through a shared `net/http.Transport`. When the upstream answers the CONNECT with a keep-alive non-2xx response and does not drain the body, Traefik returns the now desynchronized backend socket to its shared pool and reuses it for other clients. An unauthenticated attacker uses this to make a different client read the attacker's smuggled response. Traefik's default proxy is `net/http/httputil.ReverseProxy` over a shared `http.Transport`, so it inherits the same root cause as the Caddy `reverse_proxy` CONNECT pool poisoning. Traefik ships one partial mitigation Caddy does not. The entrypoint option `sanitizePath` (default `true`) rewrites the forwarded CONNECT's empty path to `/`, so Traefik emits `CONNECT /` instead of authority-form `CONNECT host:port`. This is not a reliable defense. It avoids the smuggle only against backends that reject `CONNECT /` by closing the connection (Apache, nginx). Backends that answer `CONNECT /` with a keep-alive non-2xx and leave the body undrained still cross. That set includes any Go `net/http` server and gunicorn/Flask. Confirmed on the official image `traefik:v3.6.23` (a currently supported release), default configuration, against stock `go-httpbin` (Go) and `kennethreitz/httpbin` (Python gunicorn/Flask), attacker and victim in separate containers, over both HTTP/2 and HTTP/3. ## Affected - `traefik:v3.6.23` (official image) and current v3, default configuration, standard proxy to an HTTP/1.1 upstream. Backend keep-alive pooling is on by default (`MaxIdleConnsPerHost` 200). - Attacker frontend is HTTP/2 or HTTP/3. An HTTP/1.1 frontend is not affected. - The upstream keeps the connection alive after a non-2xx to the forwarded CONNECT and does not drain the body. - The experimental FastProxy implementation is not affected (see Not affected). ## Details Three behaviors compose. 1. Traefik forwards a plain CONNECT as an ordinary proxied request. The default proxy is `httputil.ReverseProxy` with a shared `http.Transport` (`pkg/proxy/httputil/proxy.go`). The director assigns the outbound `URL.Host` directly and does not reject CONNECT, leaving the request body a live stream. The client places a raw HTTP/1.1 request in that body (H2/H3 DATA frames), which is written onto the backend socket after the CONNECT header block. 2. `net/http` writes the CONNECT body unframed and pools the socket. For a CONNECT the transport writes the body with no `Content-Length` and no `Transfer-Encoding`. The upstream answers a keep-alive non-2xx and parses the trailing bytes as a pipelined request. Go reads the non-2xx response and returns the socket to the shared idle pool once the request body reaches EOF (the `wroteRequest` gate), while the smuggled request's response is still pending. 3. Desynchronized reuse. The smuggled request targets a slow endpoint so its response arrives after the socket is pooled. A different client that reuses the socket reads the pending smuggled response as its own. `sanitizePath` (default `true`, `pkg/server/server_entrypoint_tcp.go`) calls `req.URL.JoinPath()`, which turns the CONNECT's empty path into `/`. Traefik emits `CONNECT /`. Whether that stops the smuggle depends only on the backend: Apache and nginx answer `400 Bad Request` with `Connection: close` (socket torn down, no cross); Go `net/http` and gunicorn/Flask
AI Analysis
Technical Summary
Traefik's default reverse proxy forwards HTTP/2 or HTTP/3 CONNECT requests and their bodies to HTTP/1.1 upstreams using a shared net/http.Transport connection pool. If the upstream responds to the CONNECT with a keep-alive non-2xx status and does not drain the request body, the backend socket becomes desynchronized. Traefik then returns this socket to the shared idle pool, where it can be reused by other clients. An attacker can exploit this by smuggling a response that a different client will read, resulting in cross-user response poisoning. The sanitizePath option rewrites the CONNECT path to '/', which prevents exploitation only if the backend closes the connection on such requests; backends like Go net/http and gunicorn/Flask that keep connections alive remain vulnerable. The vulnerability is fixed by deferring the CONNECT payload until tunnel acceptance, not returning CONNECT connections to the shared pool, and discarding the CONNECT body in ForwardAuth paths. The experimental FastProxy implementation is not affected.
Potential Impact
An unauthenticated attacker can cause a victim client to receive a response crafted by the attacker due to connection desynchronization in Traefik's shared backend keep-alive pool. This cross-user response poisoning may expose another user's authenticated or private content. The vulnerability affects default configurations of Traefik proxying HTTP/2 or HTTP/3 CONNECT requests to HTTP/1.1 upstreams that keep connections alive after non-2xx CONNECT responses without draining the body. This can lead to serious confidentiality breaches.
Mitigation Recommendations
A fix is available and has been released in Traefik versions 2.11.53, 3.6.24, and 3.7.9. Users should upgrade to these or later versions to remediate the vulnerability. The default sanitizePath option is not a reliable defense on its own. The vendor's fix defers forwarding the CONNECT payload until the backend accepts the tunnel, prevents returning CONNECT connections to the shared idle pool, and discards the CONNECT body in ForwardAuth paths. Users should apply the official patches promptly.
V2: Traefik: Cross-user response poisoning via proxied CONNECT on Traefik's shared backend keep-alive pool (CVE-2026-71324)
Description
## Summary There is a critical vulnerability in Traefik's default HTTP reverse proxy that leads to unauthenticated cross-user response poisoning. When a client opens an HTTP/2 or HTTP/3 `CONNECT` request, Traefik forwards it — body included — to an HTTP/1.1 upstream over a shared `net/http.Transport`. If the upstream answers the CONNECT with a keep-alive non-2xx response without draining the body, the now-desynchronized backend socket is returned to Traefik's shared connection pool and reused for other clients, letting an attacker make a different client read a response the attacker smuggled — which may be another user's authenticated or private content. The entrypoint's `sanitizePath` option (default `true`) is not a reliable defense: backends that answer `CONNECT /` with a keep-alive non-2xx remain exploitable. The experimental FastProxy implementation was not affected. The issue is fixed by deferring the forwarded CONNECT payload until the backend accepts the tunnel, by not returning CONNECT connections to the shared idle pool, and by discarding the CONNECT body in the ForwardAuth path. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.53 - https://github.com/traefik/traefik/releases/tag/v3.6.24 - https://github.com/traefik/traefik/releases/tag/v3.7.9 ## For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> ## Summary Traefik's default reverse proxy forwards a plain HTTP/2 or HTTP/3 `CONNECT` request and its body to an HTTP/1.1 upstream through a shared `net/http.Transport`. When the upstream answers the CONNECT with a keep-alive non-2xx response and does not drain the body, Traefik returns the now desynchronized backend socket to its shared pool and reuses it for other clients. An unauthenticated attacker uses this to make a different client read the attacker's smuggled response. Traefik's default proxy is `net/http/httputil.ReverseProxy` over a shared `http.Transport`, so it inherits the same root cause as the Caddy `reverse_proxy` CONNECT pool poisoning. Traefik ships one partial mitigation Caddy does not. The entrypoint option `sanitizePath` (default `true`) rewrites the forwarded CONNECT's empty path to `/`, so Traefik emits `CONNECT /` instead of authority-form `CONNECT host:port`. This is not a reliable defense. It avoids the smuggle only against backends that reject `CONNECT /` by closing the connection (Apache, nginx). Backends that answer `CONNECT /` with a keep-alive non-2xx and leave the body undrained still cross. That set includes any Go `net/http` server and gunicorn/Flask. Confirmed on the official image `traefik:v3.6.23` (a currently supported release), default configuration, against stock `go-httpbin` (Go) and `kennethreitz/httpbin` (Python gunicorn/Flask), attacker and victim in separate containers, over both HTTP/2 and HTTP/3. ## Affected - `traefik:v3.6.23` (official image) and current v3, default configuration, standard proxy to an HTTP/1.1 upstream. Backend keep-alive pooling is on by default (`MaxIdleConnsPerHost` 200). - Attacker frontend is HTTP/2 or HTTP/3. An HTTP/1.1 frontend is not affected. - The upstream keeps the connection alive after a non-2xx to the forwarded CONNECT and does not drain the body. - The experimental FastProxy implementation is not affected (see Not affected). ## Details Three behaviors compose. 1. Traefik forwards a plain CONNECT as an ordinary proxied request. The default proxy is `httputil.ReverseProxy` with a shared `http.Transport` (`pkg/proxy/httputil/proxy.go`). The director assigns the outbound `URL.Host` directly and does not reject CONNECT, leaving the request body a live stream. The client places a raw HTTP/1.1 request in that body (H2/H3 DATA frames), which is written onto the backend socket after the CONNECT header block. 2. `net/http` writes the CONNECT body unframed and pools the socket. For a CONNECT the transport writes the body with no `Content-Length` and no `Transfer-Encoding`. The upstream answers a keep-alive non-2xx and parses the trailing bytes as a pipelined request. Go reads the non-2xx response and returns the socket to the shared idle pool once the request body reaches EOF (the `wroteRequest` gate), while the smuggled request's response is still pending. 3. Desynchronized reuse. The smuggled request targets a slow endpoint so its response arrives after the socket is pooled. A different client that reuses the socket reads the pending smuggled response as its own. `sanitizePath` (default `true`, `pkg/server/server_entrypoint_tcp.go`) calls `req.URL.JoinPath()`, which turns the CONNECT's empty path into `/`. Traefik emits `CONNECT /`. Whether that stops the smuggle depends only on the backend: Apache and nginx answer `400 Bad Request` with `Connection: close` (socket torn down, no cross); Go `net/http` and gunicorn/Flask
CVSS v4.0
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Traefik's default reverse proxy forwards HTTP/2 or HTTP/3 CONNECT requests and their bodies to HTTP/1.1 upstreams using a shared net/http.Transport connection pool. If the upstream responds to the CONNECT with a keep-alive non-2xx status and does not drain the request body, the backend socket becomes desynchronized. Traefik then returns this socket to the shared idle pool, where it can be reused by other clients. An attacker can exploit this by smuggling a response that a different client will read, resulting in cross-user response poisoning. The sanitizePath option rewrites the CONNECT path to '/', which prevents exploitation only if the backend closes the connection on such requests; backends like Go net/http and gunicorn/Flask that keep connections alive remain vulnerable. The vulnerability is fixed by deferring the CONNECT payload until tunnel acceptance, not returning CONNECT connections to the shared pool, and discarding the CONNECT body in ForwardAuth paths. The experimental FastProxy implementation is not affected.
Potential Impact
An unauthenticated attacker can cause a victim client to receive a response crafted by the attacker due to connection desynchronization in Traefik's shared backend keep-alive pool. This cross-user response poisoning may expose another user's authenticated or private content. The vulnerability affects default configurations of Traefik proxying HTTP/2 or HTTP/3 CONNECT requests to HTTP/1.1 upstreams that keep connections alive after non-2xx CONNECT responses without draining the body. This can lead to serious confidentiality breaches.
Mitigation Recommendations
A fix is available and has been released in Traefik versions 2.11.53, 3.6.24, and 3.7.9. Users should upgrade to these or later versions to remediate the vulnerability. The default sanitizePath option is not a reliable defense on its own. The vendor's fix defers forwarding the CONNECT payload until the backend accepts the tunnel, prevents returning CONNECT connections to the shared idle pool, and discards the CONNECT body in ForwardAuth paths. Users should apply the official patches promptly.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-3ccp-42pg-hgv6
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-71324"]
- Ecosystems
- ["Go"]
- Database Specific Severity
- HIGH
- Cvss Version
- 4.0
Threat ID: 6a74cf65bf8831d53919900c
Added to database: 08/06/2026, 18:16:05 UTC
Last enriched: 08/06/2026, 18:20:12 UTC
Last updated: 08/06/2026, 18:25:10 UTC
Views: 2
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.