Connection-scoped NTLM/Kerberos sticky round tripper is not keyed by service, applying one service TLS client config to another

Summary

There is a high severity vulnerability in Traefik's NTLM and Kerberos (Negotiate) backend authentication support. When a backend answers a request with a WWW-Authenticate: NTLM or Negotiate challenge, Traefik keeps a dedicated backend round tripper in the client connection context so that the next requests on that client connection reuse the authenticated backend connection. That round tripper carries the whole transport configuration of the ServersTransport that created it, including its TLS client configuration, but the slot holding it was shared by every ServersTransport: once armed by one service, it was reused for every later request on the same client connection, including requests routed to another service using a different ServersTransport. The backend connection of that second service was then established with the first service's TLS settings instead of its own: its root CAs, server name and certificate verification were not applied, and the first service's client certificate was presented to its backend. An unauthenticated client can arm the slot with an ordinary request to the first service and then reach the second one on the same keep-alive connection, silently disabling the operator's TLS policy on that backend leg. The dedicated round tripper is now kept per ServersTransport, so a service can only ever reuse a round tripper it created.

Traefik v3.0 through v3.6 are affected and no longer receive patches; 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.