Traefik 3.7.13 and 2.11.57: HTTP/3 Identity Reuse and Routing Bypasses

On 7 September 2026 Traefik published five security advisories, fixed in v3.7.13 and v2.11.57, which had been released three days earlier. The most severe, CVE-2026-88007 (CVSS 4.0 score 9.1), lets one HTTP/3 client inherit a backend connection already authenticated as another user over NTLM or Kerberos. Two others let requests skip the routing and middleware decisions that Traefik is usually trusted to make, including authentication.

A recurring note across the advisories: Traefik v3.0 to v3.6 are end of life and won't get fixes on their own lines. Users there have to move to v3.7.13.

What's affected

HTTP/3 identity reuse. On HTTP/1.1 and HTTP/2, Traefik keeps a separate backend connection pool per client connection for routes whose backend binds identity to the connection with NTLM or Negotiate (Kerberos). The HTTP/3 entrypoint never set that up, so it fell back to the shared transport. An unrelated HTTP/3 client could get a backend connection already authenticated as someone else and act as them without their credentials. The conditions are specific: HTTP/3 enabled on the entrypoint, an NTLM or Negotiate backend, and backend keep-alive.

Rootless request targets. A request line like GET http:http://internal-vhost/admin HTTP/1.1 parses in Go with an empty path. Traefik made every routing, path-sanitization, middleware and access-log decision as if the path were /, then forwarded the original target to the backend byte for byte. Against a backend that treats that target as a path, the advisory describes cross-vhost routing bypass, path-scoped authorization bypass and access-log evasion, unauthenticated and with default entrypoint settings. Access logs record these requests as GET / HTTP/1.1.

h2c tunnels. Traefik forwarded a client's Upgrade: h2c header. If a backend accepted the upgrade and answered 101 Switching Protocols, Traefik turned the connection into a raw tunnel, and later HTTP/2 requests on it never passed through Traefik's router or middleware. A public route and a BasicAuth-protected route on the same backend become one route. Traefik notes that common off-the-shelf servers were not exploitable in its testing.

How to check if you're exposed

Find the version on every instance, including Kubernetes ingress deployments:

traefik version
kubectl get deploy,ds -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"  "}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep -i traefik

Check whether any entrypoint has HTTP/3 enabled. In static configuration look for http3 under an entrypoint. In the Helm chart, look for http3 under ports:

helm get values traefik -n traefik -a | grep -n -B2 -A3 http3

Then test whether a rootless request reaches a backend with an unexpected result. Run this only against your own staging instance:

printf 'GET http:http://internal.example/admin HTTP/1.1\r\nHost: app.example.com\r\nConnection: close\r\n\r\n' \
  | nc traefik-staging.example.com 80

If the backend returns something other than what / returns, and the access log shows GET /, the instance is behaving as described in CVE-2026-88009.

What to do now

1. Upgrade to v3.7.13 or v2.11.57. If you run v3.0 to v3.6, the advisories are clear that the fix is moving to 3.7.13.
2. If you can't upgrade today and have NTLM or Kerberos backends, disable HTTP/3 on the entrypoints that serve them. Ordinary per-request authentication is not affected by CVE-2026-88007.
3. Don't share a backend between a public router and a protected router where you can avoid it. Both the h2c tunnel and the rootless target bug turn a public route into a path to protected paths on the same backend.
4. Set the alias header option. The earlier August advisory (CVE-2026-88011, fixed in 3.7.12 and 2.11.56) added an aliasHeadersStrategy entrypoint option against header-name aliases like X.Auth.User. It defaults to keep for compatibility, so it does nothing until you set it to delete or reject.
5. Don't rely on access logs alone for incident review on unpatched instances. CVE-2026-88009 logged bypass requests as GET /, and requests inside an h2c tunnel weren't logged by Traefik at all.

Why it matters

A reverse proxy is often the only place authentication, IP allowlists and rate limits are enforced. Each of these bugs shows a way the proxy's view of a request diverges from what the backend receives: a path the proxy normalized but forwarded raw, a protocol switch the proxy stopped inspecting, a connection pool the proxy shared. When the edge and the backend disagree, the backend wins, because it's the one that acts.

Defense in depth here is plain: backends that hold sensitive paths should check identity themselves, not only trust a header the proxy sets. And the end-of-life notes are worth acting on. A proxy line that stops receiving fixes is a slow-moving exposure.

Try it yourself

List each Traefik router that adds authentication middleware and the backend service it points at. Then look for any other router, without that middleware, pointing at the same service. Each match is a place where a routing bypass would turn into an authentication bypass. Move protected paths to their own service or enforce auth in the backend.

Quick check

Sources

• GHSA-qqjf-53cj-pwvv: HTTP/3 backend NTLM connection reuse (CVE-2026-88007)
• GHSA-f52w-8j3h-j724: rootless HTTP/1 request-target (CVE-2026-88009)
• GHSA-w4v4-9rw7-5326: h2c upgrade request smuggling (CVE-2026-88008)
• GHSA-v67p-phpq-fc8x: header-name sanitization bypassed via trailers (CVE-2026-88004)
• GHSA-8fcf-v89g-xpg6: BasicAuth singleflight username enumeration (CVE-2026-88010)
• GHSA-rf44-j88r-hh8c: ForwardAuth identity spoofing via dot-form header alias (CVE-2026-88011)
• Traefik v3.7.13 release
• Traefik v2.11.57 release