Apache Traffic Server CVE-2026-111814

Exploitation requires Apache Traffic Server to be configured to present client certificates on OUTBOUND (origin-facing) TLS connections and to use MORE THAN ONE distinct client certificate across transactions, while the default outbound session-sharing/pooling policy remains enabled - this is the exact condition under which a pooled session authenticated with one client certificate is reused for a transaction meant to present a different one. Deployments that do not use outbound client-certificate (mutual TLS) authentication, or that use a single client identity, or that disable session sharing, are NOT affected. Triggering the wrong reuse depends on session-pool state and timing rather than a directly attacker-injected payload, which limits deterministic exploitation. Affected versions are 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0.

The input assigns a CVSS 3.1 base score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N), which is the maximum severity and reflects a network, low-complexity, unauthenticated vector with a scope change. However, these signals should be weighed against the actual mechanism described: the flaw is not a classic remote code or data-theft primitive but a TLS outbound session-sharing defect (CWE-295) in which a pooled upstream session authenticated with one client certificate may be reused for a transaction that was configured to present a different client certificate. This is fundamentally an authentication/access-control confusion issue against ORIGIN servers, and it only manifests when Apache Traffic Server is deployed as a proxy performing mutual-TLS (client-certificate) authentication to upstreams with more than one distinct client identity. No EPSS probability, CISA KEV listing, SSVC decision, or public POC is present in the provided data, so there is no evidence of active exploitation or weaponization - exploitation status is 'no public exploit identified at time of analysis.' The 10.0 / AC:L rating therefore likely overstates real-world risk for most deployments: the dangerous condition is config-dependent (outbound client certs + default session pooling), and triggering the wrong-certificate reuse depends on pooled session timing rather than a reliable attacker-controlled input, which argues for higher attack complexity than AC:L implies. Verify the exact preconditions with the Apache advisory before treating this as broadly network-exploitable. Net: a genuine priority for the specific population of ATS operators using outbound mTLS, but closer to a low-likelihood/high-impact targeted issue than a mass-exploitable 10.0 for the general ATS user base.

An organization runs Apache Traffic Server as a forward/reverse proxy that authenticates to multiple backend origins using different client certificates, with the default outbound session-sharing policy enabled. Because ATS may reuse a pooled TLS session established with client-certificate A for a later transaction that should have presented client-certificate B, a transaction can reach an origin authenticated as the wrong identity, bypassing the intended per-transaction mTLS separation and potentially accessing data or actions authorized only for a different certificate. No public exploit code is identified in the provided data, and exploitation hinges on session-pool timing rather than a directly attacker-supplied payload.