CVE-2026-114639 in Traefik
Summary
by MITRE • 10/22/2026
Traefik 2.11.0 before 2.11.58 and 3.0.0 before 3.7.14 contains an authentication bypass because a first request preauthenticated with an Authorization: Negotiate token authenticates a socket in the globally shared backend connection pool, which is never isolated. Unauthenticated attackers on separate frontend connections can be assigned that NTLM/Kerberos-bound socket and perform reads or writes with the victim's identity.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Traefik versions 2.11.0 through 2.11.57, as well as version 3.0.0 up to 3.7.13, represents a critical authentication bypass rooted in the improper isolation of backend connection states within the reverse proxy's architecture. This flaw specifically affects systems utilizing NTLM or Kerberos authentication mechanisms via HTTP Negotiate tokens. The core technical deficiency lies in how Traefik manages its pool of persistent connections to upstream services. When an initial request arrives with a valid Authorization: Negotiate header, the proxy establishes a connection to the backend service and binds that specific socket session to the authenticated identity of the user who made the request. However, instead of isolating this authenticated state within the scope of that single client's frontend connection, Traefik places the underlying TCP socket into a globally shared backend connection pool designed for connection reuse and performance optimization.
This architectural oversight creates a severe security gap because the authentication context is not tied to the specific incoming request but rather persists on the physical network socket itself. In typical reverse proxy operations, connections are reused to reduce latency by avoiding the overhead of establishing new TCP handshakes for every subsequent request. While this improves performance, it assumes that all requests routed through a shared backend connection can be treated identically regarding access control. The vulnerability exploits the fact that when an unauthenticated attacker sends a second or subsequent request from a separate frontend connection, Traefik may assign them one of these pre-established sockets from the pool. Since the socket is already authenticated and bound to the previous victim's identity by the operating system and backend service, the proxy fails to re-verify credentials for this new request. Consequently, the unauthenticated attacker effectively hijacks the existing session, gaining access with the privileges of the original user without providing any valid authentication tokens themselves.
The operational impact of this vulnerability is profound, as it allows for complete identity impersonation and unauthorized data access. An attacker who does not possess valid credentials can read sensitive information or execute write operations on behalf of authenticated users. This bypasses all intended security controls that rely on the Authorization header to validate user permissions against upstream applications such as web servers, API endpoints, or internal services protected by Active Directory or other Kerberos/NTLM-based systems. The severity is exacerbated in environments where Traefik acts as a gateway for multiple tenants or users with varying levels of privilege, as one low-privileged user could potentially access resources reserved for high-privilege administrators if they happen to reuse the same backend connection socket. This scenario aligns closely with CWE-287, which describes Improper Authentication, and specifically relates to session management flaws where identity is not correctly bound to the transaction context.
From a threat intelligence perspective, this vulnerability facilitates attacks categorized under MITRE ATT&CK technique T1078, Valid Accounts, as it allows attackers to leverage legitimate credentials without knowing them by exploiting system behavior rather than cracking passwords or stealing tokens directly. It also touches upon CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization of Independent Circular Logic, in the context of how connection pooling logic interacts with authentication state management. The flaw is particularly dangerous because it operates silently; there are no obvious error messages indicating a security breach, and logs may simply show successful requests from valid users, making detection difficult without specialized monitoring for anomalous access patterns or unexpected data exfiltration by unauthenticated sources.
Mitigation strategies must prioritize immediate version upgrades to address the root cause within the proxy software itself. Administrators running Traefik 2.x should upgrade to version 2.11.58 or later, while those on the 3.x branch must update to version 3.7.14 or newer. These releases contain patches that ensure proper isolation of authentication contexts per frontend connection, preventing the reuse of authenticated sockets for unauthenticated requests. In environments where upgrading is not immediately feasible due to compatibility constraints, temporary mitigations should focus on disabling persistent backend connections if possible, forcing Traefik to establish a new TCP connection and re-authenticate for every single request, although this will significantly degrade performance. Additionally, implementing strict network segmentation and monitoring upstream services for unusual access patterns from IP addresses that do not correspond to known authenticated users can help detect exploitation attempts in real-time. It is also advisable to review logging configurations to ensure that authentication events are logged with sufficient detail to distinguish between initial authentications and subsequent requests on reused connections, aiding forensic analysis if a breach occurs.