GITHUB.COM/TRAEFIK/TRAEFIK/V2 · GHSA-qm9f-w54v-q2qh · Runtime
FIX → v2.11.58 · v3.7.14
Traefik can reuse a backend connection that a preauthenticating client has already logged in on, and hand that connection to an unrelated unauthenticated client. The unrelated client then acts with the victim's identity on the backend, reading or writing data the victim could access.
first public Oct 7, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Exposure requires Traefik proxying a connection-bound NTLM or Negotiate (SPNEGO/Kerberos) backend with connection reuse enabled, and a client that sends a Negotiate token on its first request instead of following the challenge-first handshake. Deployments that only proxy ordinary backends, or use the standard challenge-first flow, are not affected by the shared-pool path described.
Not affected if connection-reuse-disabled, managed-hosting, no-negotiate-backends
Who cares go, kerberos, kubernetes, ntlm, self-hosted, traefik, windows-auth
traefik version and compare against the fixed versions below.go.mod for github.com/traefik/traefik/v2 or github.com/traefik/traefik/v3.There is a high severity authentication vulnerability in Traefik's handling of connection-bound backend authentication (NTLM and SPNEGO/Kerberos "Negotiate"). For each new frontend connection, Traefik sends the first backend request through a globally shared transport and only switches that connection to an isolated, per-frontend-connection transport after it observes an NTLM/Negotiate challenge in the backend's response. When a client preauthenticates — sending a valid Authorization: Negotiate token on its first request instead of following the standard challenge-first (401) handshake — the backend authenticates the shared-pool connection on that first request and returns a successful response. Because isolation is decided only after the response is seen, the now victim-authenticated backend socket remains in the shared pool, and it is neither drained nor closed. An unrelated, unauthenticated client on a completely separate frontend connection can then be assigned that socket and act with the victim's identity, performing victim-authorized reads or writes.
Exploitation requires Traefik to proxy a connection-bound NTLM/Negotiate backend with connection reuse enabled, and a legitimate client that preauthenticates rather than following the standard challenge-first handshake. The ordinary challenge-first flow is not affected: it installs a dedicated backend transport before the credential-bearing request, so the authenticated socket never enters the shared pool. This is a distinct issue from GHSA-qqjf-53cj-pwvv (which fixed a missing HTTP/3 transport holder): it occurs on ordinary HTTP/1.1 and HTTP/2 frontend connections because the credential-bearing first request reaches the shared pool before any holder can isolate it. The behavior was introduced together with connection-bound NTLM/Kerberos support in v2.11.0 and v3.0.0. Traefik v3.0 through v3.6 are end-of-life and are also affected; they will not receive a fix on their own line, and users on those versions must upgrade to v3.7.14.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Upgrade to v2.11.58 · v3.7.14
v2.11.58v3.7.14 (v3.0 through v3.6 are end-of-life and receive no fix on their own line)If you have any questions or comments about this advisory, please open an issue.