High priorityDisclosed

Advisory · CVE-2026-114639

Preauthenticated Negotiate requests contaminate Traefik shared backend pool with the victim identity

Traefik from 2.11.0 before 2.11.58 and from 3.0.0 before 3.7.14 keeps a backend connection authenticated by a first-request Negotiate token in its globally shared pool, so an unrelated unauthenticated client can be assigned that socket and act with the victim identity. CVSS 3.1 8.7.

Advisory published October 22, 2026Independent summary
Vendor
Traefik
Product
Traefik
Identifier / CWE
CVE-2026-114639
CWE-287
Action timing
Immediate
ELI5

Explain it like I’m five

If the first thing a client does is show its pass, Traefik leaves that now-trusted backend line open in the shared pool, and the next stranger handed that line is treated as the pass holder.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Victim preauthenticates

    A legitimate client sends a valid Authorization Negotiate token on its first request instead of following the challenge-first handshake, to a connection-bound NTLM or Negotiate backend.

  2. 02Shared connection is authenticated

    The backend authenticates the shared-pool connection on that first request and returns a successful response, per Traefik.

  3. 03Socket stays in the shared pool

    Because isolation is decided only after the response is seen, the victim-authenticated socket remains in the shared pool, neither drained nor closed.

  4. 04Unrelated client inherits the identity

    An unauthenticated client on a separate frontend connection can be assigned that socket and perform victim-authorized reads or writes.

What happened

Traefik disclosed CVE-2026-114639 in its GitHub security advisory: 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 transport after it observes an NTLM or Negotiate challenge in the backend response. Traefik states that when a client preauthenticates, sending a valid Negotiate token on its first request, the backend authenticates the shared-pool connection and the now victim-authenticated socket remains in the shared pool, so an unrelated unauthenticated client can be assigned it and act with the victim identity. Traefik notes the ordinary challenge-first flow is not affected, and that this occurs on ordinary HTTP/1.1 and HTTP/2 frontend connections. The CVSS 3.1 score is 8.7, with changed scope.

Per Traefik, exploitation requires Traefik to proxy a connection-bound NTLM or Negotiate backend with connection reuse enabled, and a legitimate client that preauthenticates. The behavior was introduced with connection-bound NTLM and Kerberos support in v2.11.0 and v3.0.0. The patched releases are 2.11.58 and 3.7.14; Traefik v3.0 through v3.6 are end-of-life and also affected, will not receive a fix on their own line, and users on those versions must upgrade to v3.7.14.

What to do

  1. Inventory Traefik deployments from 2.11.0 before 2.11.58 and from 3.0.0 before 3.7.14 that proxy NTLM or Negotiate backends with connection reuse enabled.
  2. Upgrade affected deployments to Traefik 2.11.58 or 3.7.14 or later; end-of-life 3.0 to 3.6 deployments must move to 3.7.14.
  3. Until upgraded, consider disabling backend connection reuse for NTLM and Negotiate services, accepting the performance cost on those routes.
  4. Hunt for backend activity where a victim identity acts from a frontend connection that never presented that identity, especially immediately after a preauthenticated first request.
  5. Verify the deployed version on every Traefik instance after updating, including Kubernetes ingress deployments.

Management note

This is the broadest of the Traefik pool flaws because it needs no experimental feature, only a client that preauthenticates, which real clients do. Any Traefik in front of an NTLM or Negotiate backend should be on 2.11.58 or 3.7.14.