Apache Traffic Server

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month, not for the report. Traffic Server qualifies at Tier 2 through its OSS-Fuzz integration, whose primary contact is the ASF security team, so the ceiling is $5,000 and not the $15,000 Tier 1 headline. A committer has to accept the change, patches must be one to twelve months old, one-liner fixes for non-exploitable crashes are not rewarded, and sanctions and territory exclusions apply. CVE history 2 Last 12 months 82 Lifetime Parsing/validation 45 % Access control 20 % Denial of service 20 % Info disclosure 10 % Latest advisories Loading the feed Overview Traffic Server is the caching proxy Yahoo donated to the Apache Software Foundation, and it remains the edge of several very large CDNs and carriers. Yahoo and Verizon Media, Comcast, LinkedIn and Apple have all run it at scale, and it is the standard building block for an operator assembling a CDN rather than buying one. Its footprint is concentrated, so a smuggling defect here touches a small number of extremely large networks, at the point where cached responses are shared between every client behind the edge. HTTP smuggling and header parsing are 45 percent of the 82 lifetime CVEs. The ASF pays nothing for a vulnerability report sent to [email protected] , so sorona.xyz pays you directly on qualified, reproduced findings. In scope The ASF security team takes reports at [email protected] for a component shipped in the Traffic Server tree. Administrative users are treated as trusted by the project, HTTP/3 and QUIC are declared experimental and are not handled as security issues, and everything below sits inside what remains HTTP/1.1 and HTTP/2 in full, from parsing through the request and response transformation pipeline the proxy runs over both The cache in full: cache-key computation, the on-disk store, and the revalidation and eviction logic that decide what a later client is served The proxy's two legs and the framing agreement between them, where the client-facing side and the origin-facing side can disagree about where one message ends The TSAPI plugin interface and every plugin shipped in the tree, including cachekey The remap rule engine and regex remap, which decide which origin a request is sent to TLS handling in full, including SNI routing, certificate selection and the sni.yaml policy layer Out of scope HTTP/3 and QUIC, which the project declares experimental and explicitly does not treat as security issues Anything presupposing a trusted administrative user, or control over ATS binaries, scripts or configuration files Out-of-tree plugins built against TSAPI Denial of service proportional to request volume One-liner fixes for non-exploitable crashes, excluded by name in the Patch Rewards rules The Tier 1 ceiling, which Traffic Server cannot reach: it qualifies at Tier 2 through OSS-Fuzz, not as a named Tier 1 project Most-valued findings Request smuggling or desync between the client leg and the origin leg, the highest-value class here because parsing is 45 percent of the record and ATS sits at the outermost hop of very large networks Cache poisoning through cache-key confusion, where one attacker's response is stored under a key other clients will fetch. That is the single defect on a CDN edge that reaches every user behind it at once Header-parsing defects that let a client inject or strip a header the edge is supposed to control on the way to the origin Remap or SNI routing evaluation an attacker can steer, so a request reaches an origin the operator never mapped it to Memory-safety defects in the in-tree plugins or the TSAPI surface reachable from an ordinary request, since plugin code is written to a C API with far less scrutiny than the core Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Send a detailed, reproducible report to [email protected] with the exact request sequence and the remap and SNI configuration it needs Administrative users are always considered trusted by the project, so anything that presupposes control of ATS binaries, scripts or configuration files is not a vulnerability here HTTP/3 and QUIC support is declared experimental by the project and findings there are explicitly not treated as security issues Show the bug in a component shipped in the tree; out-of-tree plugins written against TSAPI belong with whoever wrote them If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for one month. That is a separate pathway capped at $5,000, since Traffic Server qualifies at Tier 2 through OSS-Fuzz rather than as a named Tier 1 project Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated with the ASF security team through [email protected] , which runs a documented process with reasonable turnaround and publishes an advisory alongside the fixed release. Patch Rewards adds no embargo term of its own, so timing is the ASF's call; hold the detail until the advisory is out, which matters here because the deployments are few, enormous and individually identifiable. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability