High priorityDisclosed

Advisory · CVE-2026-114642

Traefik NTLM round tripper reuse applies one service TLS policy to another service backend

Traefik from 2.11.0 before 2.11.58 and from 3.0.0 before 3.7.14 stores its NTLM and Kerberos backend round tripper in a connection slot not keyed by ServersTransport, so an unauthenticated client can arm it on one service and have another service backend connection made with the first service TLS settings, bypassing its root CAs, server name and certificate verification. CVSS 3.1 8.7.

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

Explain it like I’m five

Traefik keeps one shared hall pass for authenticated backends, stamped with the first service security settings. Using it for a second service means that service strict certificate checks are quietly replaced by the first service looser ones.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01First backend issues a challenge

    A client request reaches a service whose backend answers with an NTLM or Negotiate challenge.

  2. 02Round tripper is stored in a shared slot

    Per Traefik, the dedicated backend round tripper, carrying the whole transport and TLS client configuration of its ServersTransport, was kept in a slot shared by every ServersTransport.

  3. 03Attacker arms and reuses the slot

    An unauthenticated client arms the slot via the first service, then reaches another service on the same keep-alive connection.

  4. 04Second service TLS policy is bypassed

    The second backend connection is established with the first service TLS settings: its root CAs, server name and certificate verification are not applied, and the first service client certificate is presented.

What happened

Traefik disclosed CVE-2026-114642 in its GitHub security advisory: when a backend answers with an NTLM or Negotiate challenge, Traefik keeps a dedicated backend round tripper in the client connection context, but that slot was shared by every ServersTransport, so once armed by one service it was reused for later requests on the same client connection, including requests routed to another service using a different ServersTransport. Traefik states the second backend connection was then established with the first service TLS settings instead of its own, its root CAs, server name and certificate verification were not applied, and the first service client certificate was presented to its backend. Traefik states the round tripper is now kept per ServersTransport. The CVSS 3.1 score is 8.7, with changed scope.

Per Traefik, the patched releases are 2.11.58 and 3.7.14. Traefik v3.0 through v3.6 are affected and no longer receive patches, so users on those lines must upgrade to v3.7.14. Traefik v2 is affected from v2.11.0, where NTLM and Kerberos support was introduced; earlier v2 releases and Traefik v1 are not affected.

What to do

  1. Inventory Traefik deployments from 2.11.0 before 2.11.58 and from 3.0.0 before 3.7.14, especially deployments with multiple services using different ServersTransport TLS settings and any NTLM or Negotiate backends.
  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, avoid mixing services with different backend TLS policies behind the same Traefik instance where keep-alive connections can cross services.
  4. Hunt for backend connections where the presented client certificate or the verified server name does not match the service policy, and for TLS errors that stopped occurring without a configuration change.
  5. Verify the deployed version on every Traefik instance and retest cross-service keep-alive behavior after updating.

Management note

Per-service TLS policy is a security boundary, and a shared connection slot silently erased it. Multi-service Traefik instances with different backend TLS settings should treat 2.11.58 and 3.7.14 as a boundary fix, not a routine bump.