Apache Traffic Server CVE-2026-111815

Exploitation requires an ATS deployment that serves multiple SNI virtual hosts and enforces verify_client STRICT (mandatory client-certificate authentication) on at least one of them, with TLS session resumption enabled and session state shared/resumable across those SNI hosts. The attacker must be able to first establish a resumable session via a host that does not demand a client certificate, then resume it against the STRICT-protected host. Limiting factors: deployments that do not use client-certificate authentication (verify_client STRICT) are not exposed at all, and single-host or non-shared-session-cache configurations are unaffected; no user interaction or prior authentication is otherwise needed.

This is a genuine access-control flaw but not an urgent mass-exploitation priority based on available signals. The Apache-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes network-reachable, unauthenticated, low-complexity exploitation, and the base score of 7.8 (HIGH) is driven entirely by subsequent-system impact (SC:H/SI:H) with zero impact to the ATS instance itself (VC:N/VI:N/VA:N) - consistent with CWE-295: the bug lets a client bypass the client-certificate check protecting a backing virtual host rather than compromising ATS directly. No EPSS score, CISA KEV listing, or proof-of-concept was provided, so there is no evidence of active exploitation; this is 'no public exploit identified at time of analysis.' A key caveat: the AC:L/PR:N rating treats the attack as trivially reachable, but exploitation is materially gated by a specific server configuration (at least one SNI virtual host enforcing verify_client STRICT, with TLS session resumption and a shared session context across SNI hosts). That configuration dependency is not captured by CVSS attack complexity and should temper real-world urgency - verify whether your deployment actually uses verify_client STRICT before treating this as critical.

An attacker first completes a normal TLS handshake to an ATS SNI virtual host that does not require a client certificate, obtaining a resumable session ticket/ID. They then initiate a resumed TLS session but target (via SNI) a sibling virtual host configured with verify_client STRICT, and ATS honors the resumption without re-verifying the mandatory client certificate - granting access to the protected host without ever presenting a valid certificate. No public proof-of-concept was provided, and the attack is remote and unauthenticated but depends on the multi-host STRICT configuration being present.