Traefik Proxy CVE-2026-114642

Requires a Traefik deployment (2.11.0 before 2.11.58, or 3.0.0 before 3.7.14) that fronts multiple services where at least one backend performs NTLM or Kerberos/Negotiate authentication, and where per-service ServersTransport configurations differ in their root CAs, server name, or certificate verification. The attacker must induce that backend to emit an NTLM/Negotiate challenge to 'arm' the mis-keyed client-connection slot, then reach a different service over the same HTTP keep-alive connection to inherit the wrong TLS client configuration. Limiting factors: exploitation depends on connection-reuse timing (reflected as AT:P), on the presence of an NTLM/Kerberos backend, and on multiple services with divergent ServersTransport TLS settings sharing the proxy - single-service or uniform-TLS deployments are not meaningfully exposed, and the flaw compromises downstream backend trust rather than Traefik itself.

This is a genuine but conditional priority rather than a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) confirms a network-reachable, unauthenticated issue, but the AT:P flag (attack requirements present) is the critical caveat: exploitation is not fire-and-forget - the attacker must first 'arm' a shared connection slot by inducing a backend to emit an NTLM/Negotiate challenge, then race to reuse that keep-alive connection for a different service. Impact is scoped entirely to subsequent systems (VC:N/VI:N/VA:N but SC:H/SI:H), meaning Traefik itself is not directly compromised; instead the TLS trust model for a *different* backend is subverted, enabling MITM against that backend's traffic. No EPSS score, KEV listing, or public POC is present in the supplied data, so there is no evidence of active exploitation - treat the 7.0 HIGH as a theoretical-but-real trust-boundary flaw. The signals are internally consistent: a high-severity integrity/confidentiality impact on downstream services, gated by non-trivial preconditions, which argues for prompt patching in multi-tenant/multi-service Traefik deployments but not panic. Note the vulnerable-system impacts are all N while subsequent-system impacts are H - verify this scope interpretation against the vendor advisory (GHSA-cw35-4q88-3rmp) before deprioritizing based on the 'N' vulnerable-system metrics.

In an environment where one Traefik instance fronts multiple services - at least one using an NTLM/Kerberos backend with its own ServersTransport TLS settings - an unauthenticated attacker sends a request that causes that backend to issue an NTLM or Negotiate challenge, arming the shared round-tripper slot. The attacker then issues a follow-up request for a different service over the same keep-alive connection, which now reuses the first service's TLS client configuration and skips root-CA, server-name, and certificate verification for the second backend, enabling man-in-the-middle interception or impersonation of that backend. No public exploit code is identified at time of analysis, and the attack requires winning the connection-reuse timing (AT:P).