CDN Flaw Lets Attackers Magnify Traffic 350 Times Against Origin Servers

Security researchers have uncovered two denial-of-service attacks that exploit how major content delivery networks handle protocol conversion, allowing attackers to magnify a low-bandwidth request stream by up to 350 times against the servers hosting websites. The attacks, labeled "CDN Tsunami," were tested against Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly, and Tencent, with all six providers found vulnerable to the bandwidth variant and five to the connection variant. The vulnerability stems from a fundamental mismatch in how CDNs process traffic: they accept HTTP/3 connections from browsers but convert those requests to HTTP/1.1 before forwarding them to the websites they protect, creating an opportunity for massive amplification.

The bandwidth attack, called HTTP/3 Bandwidth Amplification, takes advantage of QPACK, the header compression format built into HTTP/3. Because HTTP/1.1 lacks any comparable compression mechanism, the CDN must decompress every compact index value it receives back into a complete raw header before passing the request along, meaning a request costing the attacker only a few bytes on the wire costs the origin server the full decompressed size. Attacker bandwidth stayed under 500 kilobits per second against the three CDNs supporting the QPACK dynamic table and below 5 megabits per second against the others, while bandwidth consumption measured at the origin exceeded 100 megabits per second throughout. The 350-times amplification factor applies only to Alibaba, Baidu, and Tencent, which support the QPACK dynamic table and were measured at roughly 64 concurrent streams, while the maximum on Cloudflare, CloudFront, and Fastly ranged from 36.41 times to 51.2 times. The dynamic table variant requires the attacker to first send one HTTP/3 request carrying a large header, which the CDN inserts into the table, then reference that entry repeatedly using small index values.

The connection attack, HTTP/3 Connection Amplification, targets connection capacity instead of bandwidth. Five of the six CDNs open an HTTP/1.1 connection to the origin as soon as they receive the HTTP/3 HEADERS frame, before the request body arrives, and HTTP/3 multiplexing allows a single client connection to carry multiple streams, each triggering its own backend TCP connection. The researchers report that sending DATA frames at a very low rate keeps those connections open, with the CDN continuing to treat the request as incomplete. Against an Apache server configured with a 300-second timeout and a 256-connection limit, four HTTP/3 connections, each multiplexing 96 streams, forced 384 backend connections, while Fastly required 48 connections of 8 streams because it caps backend connections at 10 per HTTP/3 connection. Response times for a benign client reached 60 seconds on Alibaba and up to 90 seconds on Baidu and CloudFront, both returning HTTP 504 Gateway Timeout errors, while Fastly rose to 15 seconds and returned HTTP 503 Service Unavailable.

The attacks work because CDNs don't support end-to-end HTTP/3, according to the research team, leaving a conversion gap that attackers can exploit. The mitigations proposed to vendors are all applied at the CDN rather than at the website level and include capping the size of any single header field entry inserted into the QPACK dynamic table at 512 bytes, limiting how many times one dynamic table entry can be referenced within a single stream to no more than 10, and enforcing a maximum decompressed HTTP/1.1 request size of 64 kilobytes. Baidu and Tencent confirmed the reports and deployed the proposed fixes, with Tencent limiting the number of CDN-to-origin connections and restricting the size of headers in the dynamic table, while the other four vendors acknowledged the disclosure and were still discussing the findings internally. The work, credited to researchers at the National University of Singapore, Fuzhou University, the University of Sheffield, and Johns Hopkins University, is scheduled for presentation at the Symposium on Reliable Distributed Systems in Rome from September 22 to 24, 2026. No CVE identifiers have been assigned, and no exploitation in the wild has been reported. The protocol gap exposes a broader architectural tension between performance optimization at the edge and security guarantees for origin infrastructure, one that vendors will need to resolve without sacrificing the speed gains that justify CDN adoption in the first place.