Apache Traffic Server flaw lets SNI and Host checks slip; fixes land in 9.2.15 and 10.1.4

The Apache Software Foundation disclosed an improper access control flaw in Apache Traffic Server on 2 October 2026, tracked as CVE-2026-102795. It was one of eight CVEs announced across three Apache projects in a single batch that also covered Apache OpenOffice and the Apache Directory LDAP API. Fixed builds are now available for both affected release lines, but according to the dev.to write-up that assembled the details, the trickier part for operators is an earlier, incorrect CVE record that may have left some teams believing they had already dealt with this exact weakness.

What the flaw is

Apache's description of the bug, as relayed by the dev.to analysis, is that the policy tying a connection's TLS Server Name Indication value to the HTTP Host header is not enforced as intended. SNI travels in the TLS handshake and tells a listener which certificate and virtual service the client expects; the Host header makes a similar claim inside the request itself. Deployments that put Traffic Server in front of multiple backends typically want those two values checked against each other, so a client cannot fetch content through an unintended route. CVE-2026-102795 covers situations where that enforcement does not hold.

The dev.to author notes that Apache has not published a step-by-step exploitation narrative, and no public proof of concept is confirmed. That narrows the practical question: which of your properties rely on SNI and Host agreement for separation, and does that separation still hold after the upgrade?

Affected versions and a misleading earlier record

The affected ranges are unusually clean to enumerate:

• Apache Traffic Server 9.0.0 through 9.2.14
• Apache Traffic Server 10.0.0 through 10.1.3

The fixed releases are 9.2.15 and 10.1.4.

There is a complication. A prior record, CVE-2026-41920, described the same access control weakness but listed an incorrect 9.x range and named 9.1.15 as the fix, according to the dev.to write-up. Anyone who built a change ticket around that earlier record may have concluded they were already current. They were not, and deployments on 9.x remain exposed until they reach 9.2.15.

Severity: two numbers, neither settled

Reporting by SecurityOnline on the advisory batch placed CVE-2026-102795 at the top of its severity table with a 9.3 CVSSv3 score, while the prose in the same report described it as a 7.0 under CVSS 4.0. The dev.to author points out that both figures appear in the same secondary report and that NVD had not published an analysed record at the time of writing, so the precise score should be treated as unsettled rather than established.

Exposure in the wild

A ZoomEye query for Apache Traffic Server returned 311,469 matching assets on 3 October 2026, while a query correlated to the CVE identifier itself returned zero results, which is expected for a freshly published CVE that indexers have not yet mapped. The dev.to analysis stresses that the product figure only describes the size of the observable population: it cannot distinguish a current build from an older one, and it cannot tell whether SNI and Host matching is part of any given deployment's design.

How to patch and verify

Upgrade to 9.2.15 or 10.1.4, then confirm the change rather than assuming it. The dev.to write-up suggests a three-part check. First, verify the running build identifier through your normal configuration endpoint or package metadata. Second, if the deployment depends on SNI and Host agreement, reproduce the routing decision in a staging environment with both a matching and a deliberately mismatched pair. Third, keep the evidence attached to the change record, because the superseded CVE makes an "already patched" conclusion plausible and wrong for a reviewer to reach.

Why it matters

Traffic Server typically runs at the edge, as a caching proxy or reverse proxy in front of many backends. If the SNI-to-Host check can be bypassed, the virtual-service separation an operator believes they have may not exist in practice, quietly widening what a client can reach. The severity confusion is also instructive: with two published scores and no NVD analysis yet, prioritisation should rest on architecture, not on the number. Finally, the superseded CVE-2026-41920 record is a process warning. Bad vulnerability metadata can create a false "done" state in change management, and a version inventory, verified against the corrected fixed releases, is the only reliable way to know where a fleet actually stands.