A gap between two versions of HTTP
Most major content delivery networks (CDNs) now speak Hypertext Transfer Protocol version 3 (HTTP/3), the newest version of the protocol that underlies the web, to the browsers and apps that connect to them. But behind the scenes, many of those same CDNs still talk to the origin servers they protect using the older HTTP/1.1. That translation step, converting one protocol into another on every request, is where a newly disclosed pair of attack techniques does its damage.
Researchers from the National University of Singapore, Fuzhou University, the University of Sheffield, and Johns Hopkins University describe the techniques, named collectively "CDN Tsunami," in a paper set for presentation at the Symposium on Reliable Distributed Systems (SRDS) in September 2026. The Hacker News first reported the findings on August 20. The core claim: a small amount of traffic sent by an attacker to a CDN can arrive at the origin server carrying up to 350 times the bandwidth, without the attacker needing anything more than an ordinary connection.
How the amplification works
The first technique, HTTP/3 Bandwidth Amplification (HBA), exploits QPACK, the header-compression system built into HTTP/3. QPACK lets a client refer to a previously sent header using a short index number instead of resending it in full. HTTP/1.1 has no equivalent shorthand, so when a CDN converts a QPACK-compressed HTTP/3 request into an HTTP/1.1 request for the origin, it has to expand every compressed reference back into its full, uncompressed text. A request that costs the attacker only a few bytes to send can cost the origin server far more to receive.
The second technique, HTTP/3 Connection Amplification (HCA), works differently: an attacker trickles small pieces of a request just quickly enough to keep the CDN's connection to the origin open, tying up the origin's available connections and crowding out legitimate traffic.
The researchers tested six major CDNs: Cloudflare, Amazon CloudFront, Fastly, Alibaba, Baidu, and Tencent. All six proved vulnerable to the bandwidth technique. Five of the six were vulnerable to the connection technique; Cloudflare was the exception, because it waits to receive a client's full HTTP/3 request before opening any connection to the origin, which closes off that particular avenue.
The size of the bandwidth amplification varies by CDN and by which part of QPACK is in play. Using only QPACK's static table, the baseline set of common headers built into the protocol, the researchers measured amplification of roughly 36 to 66 times across the tested CDNs. Alibaba, Baidu, and Tencent also support QPACK's optional "dynamic table," which lets a connection register custom headers for later reuse, and enabling that pushed their amplification up to the reported maximum of roughly 350 times, measured at around 64 concurrent streams. Cloudflare, CloudFront, and Fastly, which do not expose the dynamic table to client requests in the same way, topped out lower, between roughly 36 and 51 times.
Scale and response
To gauge how exposed the wider internet is, the researchers ran a large measurement sweep and found approximately 42,330 subdomains that appeared potentially vulnerable to the techniques. No CVE (Common Vulnerabilities and Exposures) identifier has been assigned to either technique, and neither the researchers nor the outlets covering the disclosure have reported evidence of exploitation in the wild so far.
The researchers disclosed their findings to the affected vendors before publication. Baidu and Tencent have already acknowledged the issue and deployed mitigations, according to the paper; the researchers noted the two companies paid bug bounties of roughly $150 and $350 respectively. The remaining vendors were still in discussion with the researchers at the time of disclosure. Because the underlying gap sits inside the CDN's own protocol-translation layer, any fix has to happen on the CDN side. A website operator running behind a vulnerable CDN cannot patch this on their own.
What it means in practice
For a website or application operator, this is not a flaw you can address directly unless you control your own reverse proxy rather than relying entirely on a CDN's HTTP/3 termination. The practical steps are to check with your CDN provider on whether and when they plan to mitigate HBA and HCA, and to watch for unusual spikes in origin-side bandwidth or connection counts that are disproportionate to the client-side traffic reaching the CDN's edge, since that mismatch is the signature these techniques would leave behind. Given that two of the six vendors tested have already shipped fixes, providers who have not yet responded publicly are the ones worth following up with directly.
