CVE-2026-71324 is a critical (CVSS 9.1) request smuggling flaw in the Traefik reverse proxy. A CONNECT request can desynchronize a pooled backend connection, so a different client may read someone else's response. Fixed in Traefik 2.11.53, 3.6.24 and 3.7.9, so upgrade your release line.
What's affected
Traefik versions before 2.11.53, before 3.6.24 and before 3.7.9, depending on your release line. The fixed versions are 2.11.53, 3.6.24 and 3.7.9, which match the record and the project's merged fixes.
The conditions are specific. The problem involves Traefik's default HTTP reverse proxy forwarding a plain HTTP/2 or HTTP/3 CONNECT request and its body to an HTTP/1.1 backend. It needs a backend that answers the CONNECT with a keep-alive response that is not a success status and does not read the request body.
A second path exists through the ForwardAuth middleware. The record says that with forwardBody set to true and preserveRequestMethod set to true, ForwardAuth can re-send a CONNECT with the buffered body, which exposes the connection pool used for auth calls to the same problem.
How to check if you're exposed
Find the Traefik version.
traefik version
For a container, run the same command inside it.
docker exec <container> traefik version
For Kubernetes, read the image tag in the Deployment or Helm values.
kubectl get deploy -A -o wide | grep -i traefik
Then check the configuration for two things. First, whether entry points accept HTTP/2 or HTTP/3 from untrusted clients (HTTP/2 is on by default on TLS entry points). Second, whether any ForwardAuth middleware sets both forwardBody and preserveRequestMethod.
What to do now
- Upgrade to 2.11.53, 3.6.24 or 3.7.9, or a later release in your line.
- Check ForwardAuth middlewares for forwardBody together with preserveRequestMethod, and turn them off if you do not need them until you have upgraded.
- If you cannot upgrade soon, consider rejecting CONNECT requests at an earlier layer such as a load balancer or web application firewall, if your setup allows it.
- Review whether any backend behind Traefik answers unusual methods with keep-alive error responses.
- After upgrading, retest authenticated routes and confirm responses go to the right client.
Why it matters
The record maps this to CWE-444, inconsistent interpretation of HTTP requests, better known as request smuggling. A reverse proxy keeps a pool of open connections to its backends and reuses them for different clients. That only works if each connection is left in a clean state after a request ends.
Here the proxy forwarded a CONNECT request with a body, the backend refused the CONNECT but left the body unread, and the connection went back into the pool still holding stray data. The next client to use that connection could receive a response that was meant for someone else. The record warns the response can include authenticated or private content.
The project's fixes, as their titles state, do three things: they stop adding CONNECT requests back to the pool, they hold the request payload until the backend accepts the tunnel, and they discard the CONNECT body in ForwardAuth and reject some CONNECT requests. Those are sensible layers for one underlying mistake.
The record's KEV flag is false and it does not describe attacks in the wild.
What to test after upgrading
Request smuggling bugs are about state shared between users, so the useful test is behavioral. After you upgrade, run your usual smoke tests for authenticated routes and confirm that responses carry the right user's content. Watch error rates on routes served over HTTP/2 and HTTP/3 for a day or two, since the fix changes how CONNECT requests are handled and some unusual client traffic may now be rejected.
If you want a defense in depth step, check whether you need CONNECT at all on the public entry points. Most web applications never use it. A rule at an outer layer, such as a load balancer or web application firewall, that drops CONNECT requests on those routes removes the trigger no matter which proxy version is behind it. That is a mitigation, not a substitute for the fix.
Why shared connection pools deserve attention
Connection pooling is a normal performance feature, and it only works because every request leaves the connection clean. Whenever a proxy, an auth subrequest or an internal client reuses connections, ask what happens when a backend does something unusual: answers early, ignores a body, or keeps a connection open after an error. The ForwardAuth path in this advisory shows the same problem can sit in a second pool you did not think about. Inventory the places in your gateway that make backend calls on behalf of users, and make sure each of them is covered by the upgrade.
The free in-browser dependency scan at gold.safeguard.sh/scan can show whether a project you maintain pulls in an affected package, and the Gold vulnerability directory keeps the record for this CVE.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect me if I only use HTTP/1.1?
The record describes HTTP/2 and HTTP/3 CONNECT requests forwarded to an HTTP/1.1 backend. Upgrade regardless, since the fix also covers ForwardAuth.
Which release fixes it in the 3.7 line?
3.7.9. The 3.6 line is fixed in 3.6.24 and the 2.11 line in 2.11.53.
Sources
- Traefik pull request 13542, defer the CONNECT payload
- Commit: do not add back CONNECT requests to the pool
- Commit: discard CONNECT body in forwardauth
Last reviewed: 19 October 2026.
