CVE-2026-111814 in Traffic Server
Summary
by MITRE • 10/21/2026
Apache Traffic Server's default outbound session-sharing policy can reuse a pooled TLS session authenticated with one client certificate for a transaction configured to present a different one.
This issue affects Apache Traffic Server: from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability in Apache Traffic Server represents a critical flaw within its Transport Layer Security session management logic, specifically concerning how outbound connections handle client certificate authentication during connection pooling and reuse. In modern web architectures, reverse proxies like Apache Traffic Server often maintain persistent connections to upstream origin servers to improve performance by avoiding the overhead of repeated TLS handshakes. This optimization relies on caching SSL/TLS sessions so that subsequent requests can resume an existing session rather than performing a full handshake. However, in versions ranging from 9.0.0 through 9.2.15 and 10.0.0 through 10.2.0, the default outbound session-sharing policy fails to adequately isolate TLS sessions based on the specific client certificate presented for each transaction. This architectural oversight allows a pooled connection established with one set of credentials to be erroneously reused when a different client certificate is required by the application logic or configuration directives.
From a technical perspective, this flaw constitutes an identity confusion vulnerability where the proxy server incorrectly associates a previously authenticated TLS session with a new request that demands distinct authentication parameters. When a transaction is configured to present a specific client certificate for mutual TLS authentication, the system should ensure that the underlying connection matches those exact credentials. Instead, due to the overly permissive session reuse policy, the server may attach an existing pooled connection where the peer has already authenticated using a different identity. This bypasses the intended security controls because the upstream server accepts the request based on the stale certificate embedded in the resumed TLS session rather than validating that it matches the current transaction's requirements. The issue stems from insufficient validation of client certificate attributes against cached session metadata before reusing the connection, leading to a state where authentication context is decoupled from the actual network flow.
The operational impact of this vulnerability is severe, particularly in environments utilizing mutual TLS for strict access control between services or when proxying requests on behalf of multiple distinct clients with separate identities. An attacker who can influence which upstream server receives traffic might exploit this to impersonate another client identity if they have previously established a connection using their own certificate and the system erroneously reuses it under different credentials, although more commonly the risk involves internal service-to-service communication integrity being compromised. If an organization relies on client certificates for authorization decisions at the origin server, this flaw allows requests authenticated with one identity to be processed as if they originated from another, potentially leading to unauthorized data access or actions performed under a false identity. This undermines the principle of least privilege and can facilitate lateral movement within trusted networks that depend on certificate-based authentication for security boundaries.
This vulnerability aligns closely with CWE-290, which describes Authentication Bypass by Spoofing, as well as CWE-613, Insufficient Session Expiration, in the context of session reuse without proper credential validation. In terms of attack vectors and techniques, it relates to MITM attacks where an intermediary can manipulate connection states or exploit misconfigured trust relationships within a proxy chain. It also touches upon aspects of improper input validation regarding security contexts associated with network resources. The flaw highlights the complexity of managing stateful connections in high-performance proxies and underscores the necessity for rigorous separation of session pools based on all relevant authentication parameters, not just hostnames or ports.
To mitigate this risk, organizations running affected versions must upgrade Apache Traffic Server to version 9.2.16, 10.1.5, or 10.2.1 immediately, as these releases contain the necessary patches to enforce strict isolation of TLS sessions based on client certificate identities. Until upgrading is feasible, administrators should consider disabling outbound connection pooling for upstream servers that require mutual TLS authentication with distinct client certificates per transaction. Additionally, implementing rigorous monitoring and logging around TLS session resumption events can help detect anomalous patterns indicative of this exploitation attempt. Regular audits of proxy configurations to ensure that security policies align with the actual requirements of downstream services are essential to prevent similar misconfigurations in other areas of the infrastructure.