SURIQ
The Apache Software Foundation shipped a big security release for Apache Traffic Server this week, and buried in the batch is one flaw that stands apart. CVE-2026-33267 is scored a maximum 10.0 on the Common Vulnerability Scoring System (CVSS), the industry's 0-to-10 severity scale, and it does something worse than crash the proxy: it turns the proxy into a weapon against everything sitting behind it.
Apache Traffic Server is a caching proxy that sits at the front door of large web platforms, taking client requests, caching responses, and forwarding traffic to origin servers. That position is exactly what makes this bug matter. An attacker who can send ordinary web requests to a vulnerable server gets two things at once: the ability to smuggle a hidden request past the proxy's checks, and the ability to forge the internal bookkeeping the proxy trusts about that traffic.
What actually broke
Two kinds of headers were not being stripped from untrusted requests. The first is hop-by-hop headers, the connection-level fields that are only meant to travel one link at a time and should never be passed along to the next server. The second is Apache Traffic Server's own internal headers, the ones it marks with a leading @ character. Those @ headers are private metadata the proxy uses to carry state between its own components and plugins. By design they live inside the server and are supposed to be discarded the moment they arrive from a client.
When a proxy fails to strip either class of header from a client request, it desynchronizes from the servers behind it. The proxy reads the request one way, the origin reads it another, and an attacker slots a second, hidden request into that gap. This is HTTP request smuggling, and its payoff is not a single victim. It poisons shared caches, slips past front-end access controls that never see the smuggled request, and can serve one user's response to another. The forged @ metadata compounds it: internal state the proxy would normally trust as its own can now be dictated by an outsider.
Who is exposed, and to what
The flaw needs no login and no user interaction. Any host running an affected build and reachable by an attacker is in scope. The affected and fixed versions are narrow enough to check in a minute.
| Release branch | Affected versions | Patched in |
|---|---|---|
| 9.2.x | 9.2.0 through 9.2.14 | 9.2.15 |
| 10.1.x | 10.1.0 through 10.1.3 | 10.1.4 |
If you run 9.2.0 through 9.2.14, or 10.1.0 through 10.1.3, you are affected. The fixes land in 9.2.15 and 10.1.4, per the Apache CVE record and the project's security advisory, which credits Charlie Campbell and the Apache community with the report. Header-handling bugs like this keep surfacing across the proxy tier: we recently covered a crafted request forcing Apache Camel's Solr routes to call out to an attacker and a heap overflow in a config most NGINX servers actually run. The common thread is input a defender assumed the edge would sanitize, and did not.
Is anyone exploiting it yet?
No public proof-of-concept is circulating at the time of writing, and the flaw is not on the US cybersecurity agency's Known Exploited Vulnerabilities list. Do not read that as breathing room. A maximum-severity, network-reachable flaw in edge infrastructure, with a patch already published, is the exact profile that draws exploit work fast. The advisory and the version numbers are public; the reverse-engineering starts from there.
The severity split tells you where to look
Here is a detail worth pausing on. Under CVSS version 3.1 this rates 10.0, but under the newer version 4.0 formula the same flaw scores 7.7. That gap is not a contradiction, it is a map. The 4.0 vector puts the impact on the subsequent system, not on Traffic Server itself. In plain terms: the proxy is the weapon, and the damage lands downstream, on origin servers, on the shared cache, on the other clients whose traffic runs through the same machine. So model your exposure from the origin outward, not just at the proxy. The log that proves you were hit may not be on the Traffic Server host at all. Watch for cache entries that should not exist, responses served to the wrong session, and access-control decisions that leave no matching authentication record. Request smuggling is a desync you often cannot see from the front door, which is precisely why it is dangerous. This is the kind of cross-boundary pattern a managed detection service maps to MITRE ATT&CK and alerts on, but the first move is still the patch.
Patch now, and patch the whole batch
Upgrade to Apache Traffic Server 9.2.15 or 10.1.4. Do not cherry-pick. CVE-2026-33267 shipped alongside a large set of other fixes in the same release, including additional request-smuggling and HTTP/2 handling issues, so a partial upgrade that closes one hole can leave the next one open. Take the full version bump, restart, and confirm the running build reports the patched version. If you sit behind a content delivery network or a managed proxy, ask your provider which Traffic Server build they run and when it moves. The window between a published fix and a working exploit for edge software is short, and this one is already open.