CVE-2026-121966 in Traefik
Summary
by MITRE • 11/04/2026
Traefik 2.x before 2.11.60 and 3.x before 3.7.16 sends ForwardAuth subrequests (and, in 3.7, Ingress NGINX auth-url requests) through an auth-server connection pool shared by all clients, exposing connection-bound NTLM or Negotiate authentication. An unauthenticated attacker can reuse another user's authenticated connection, receiving the victim's identity via authResponseHeaders to access backends as that user.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in Traefik versions 2.x prior to 2.11.60 and 3.x prior to 3.7.16 represents a critical flaw in how the reverse proxy manages authentication connections for external authorization services, specifically those utilizing ForwardAuth or Ingress NGINX auth-url configurations. This issue stems from an architectural decision where Traefik employs a shared connection pool for upstream connections destined for the designated authentication server. While this pooling mechanism is designed to optimize resource utilization and reduce latency by reusing existing TCP connections rather than establishing new ones for every request, it fails to adequately isolate sessions when dealing with connection-bound authentication protocols such as NTLM or Negotiate (Kerberos). In these specific protocol implementations, the identity of the authenticated user is intrinsically tied to the underlying network socket. By allowing multiple distinct client requests from different users to traverse the same physical TCP connection to the auth-server, Traefik inadvertently creates a scenario where authentication state becomes shared across unrelated sessions rather than being strictly bound to individual request contexts.
The technical flaw manifests when an unauthenticated or malicious actor sends a request that triggers a ForwardAuth subrequest to the configured external authorization server. Because the proxy reuses an existing connection from its pool, there is a significant probability that this new request will be routed through a TCP socket currently in use by another authenticated user who previously established a session with the auth-server. When the authentication server processes these requests over the shared connection, it may return headers containing the identity and credentials of the original owner of that connection rather than evaluating the current requester's actual state. Consequently, Traefik interprets the response headers associated with this reused connection as valid proof of authorization for the new requestor. This allows an attacker to bypass authentication mechanisms entirely by piggybacking on the active session of a legitimate user, effectively impersonating them within the protected backend services without possessing any valid credentials themselves.
The operational impact of this vulnerability is severe, leading directly to unauthorized access and identity spoofing across all backends configured with ForwardAuth or Ingress NGINX auth-url middleware that rely on NTLM or Negotiate authentication schemes. An attacker can exploit this flaw to gain the same level of access as a victim user, potentially accessing sensitive data, modifying configurations, or executing actions under the guise of an authorized individual. This undermines the fundamental security principle of identity isolation and breaks the trust model established by external authorization services. The risk is particularly acute in environments where high concurrency leads to frequent connection reuse, increasing the likelihood that an attacker's request will land on a socket currently holding valid authentication context for another user.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as it involves failing to properly verify the identity of a user due to flawed session management logic. Furthermore, from a tactical perspective within the MITRE ATT&CK framework, this exploit maps to T1078 Valid Accounts, specifically the subcategory of using legitimate credentials obtained through other means or exploiting trust relationships. The attacker does not need to crack passwords or steal tokens in the traditional sense; instead, they leverage the infrastructure's own connection management behavior to hijack an active session context. This represents a sophisticated form of authentication bypass that exploits protocol-level assumptions about connection identity rather than breaking cryptographic protections.
To mitigate this risk, organizations running affected versions of Traefik must upgrade immediately to version 2.11.60 or later for the v2 series and version 3.7.16 or later for the v3 series. These releases contain patches that address the connection pooling logic to ensure that authentication state is correctly isolated per request, preventing the leakage of identity information across different users sharing a physical socket. In environments where upgrading is not immediately feasible, administrators should consider disabling ForwardAuth middleware if NTLM or Negotiate protocols are in use and transitioning to alternative authentication methods such as OAuth2 or OIDC, which rely on token-based state rather than connection-bound credentials. Additionally, configuring the proxy to limit connection reuse or enforce strict header isolation can provide a temporary layer of defense against session hijacking via shared connections until the software update is applied.