Cybersecurity researchers have disclosed two denial-of-service (DoS) attacks that exploit how major content delivery networks (CDNs) convert client-facing HTTP/3 traffic into HTTP/1.1 requests to the websites they front, amplifying a low-bandwidth request stream by up to 350x against the origin server.
The attacks, collectively named “CDN Tsunami,” were evaluated against Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly, and Tencent.
All six were found susceptible to the bandwidth variant and five to the connection variant, with Cloudflare unaffected by the latter because it buffers the complete request before opening a connection to the origin.
The attack requires a website hosted on one of the six providers, with HTTP/3 serving at the edge, and no configuration changes on the website’s part. The paper lists HTTP/3 as enabled by default at Cloudflare and CloudFront.
However, Cloudflare’s documentation describes HTTP/3 as available on all plans and provides steps to enable it, rather than stating it is enabled by default. AWS documentation gives http2 as the default HTTP version for new CloudFront distributions.
The 350x factor applies only to Alibaba, Baidu, and Tencent. These three providers support the QPACK dynamic table, and it was measured at roughly 64 concurrent streams, with the maximum on Cloudflare, CloudFront, and Fastly ranging from 36.41x to 51.2x.
No CVE identifiers have been assigned, and no exploitation in the wild is reported. While Baidu and Tencent confirmed the reports and deployed the proposed fixes, the researchers say every mitigation proposed is applied at the CDN rather than at the origin website.
The two techniques are named HTTP/3 Bandwidth Amplification (HBA) and HTTP/3 Connection Amplification (HCA), and both rest on the same deployment gap, in which a CDN speaks HTTP/3 to the browser but only HTTP/1.1 to the website behind it, a mismatch the team said exists because “CDNs do not support end-to-end HTTP/3.”
HBA leverages QPACK, the header compression format introduced with HTTP/3. Because HTTP/1.1 carries no equivalent mechanism, the CDN has to expand every small index value it receives back into a full raw header before forwarding the request, so a request costing the attacker a few bytes on the wire costs the origin the decompressed size.
Attacker-side bandwidth stayed below 500 Kbps against the three CDNs supporting the dynamic table and below 5 Mbps against the rest, while bandwidth consumption measured at the origin exceeded 100 Mbps throughout.
The dynamic table variant requires the attacker first to send one HTTP/3 request carrying a large header, which the CDN inserts into the table, and then reference that entry repeatedly using small index values. Support is limited to Alibaba, Baidu, and Tencent, each advertising a 4KB table with a maximum entry size of 3,072 bytes.
The maximum bandwidth amplification factors measured using the QPACK static table are as follows –
- Baidu, 66.06x, dynamic table supported
- Alibaba, 65.8x, dynamic table supported
- Tencent, 54.08x, dynamic table supported
- Amazon CloudFront, 51.2x, no dynamic table support
- Cloudflare, 48.27x, no dynamic table support
- Fastly, 36.41x, no dynamic table support
HCA targets connection capacity rather than 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 of which triggers its own backend TCP connection. Sending DATA frames at a very low rate then 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, while Fastly rose to 15 seconds and returned HTTP 503 Service Unavailable.
Tencent closed the client-side connection roughly 10 seconds after receiving a probe request and returned no response.
The experiments were bounded by limits the researchers imposed on themselves, with the origin capped at 100 Mbps and the attacker at 30 Mbps, and no test above those figures is reported. The paper states that the attacks scale to higher-capacity servers, a claim it does not test.
The amplification factor was also found to peak near 64 concurrent streams and then decline, which the researchers attribute to CPU overhead at the CDN edge. However, no edge CPU measurements are presented.
To gauge exposure, the team enumerated subdomains under the Tranco Top 1M list, crawled their CNAME and NS records, matched them against known CDN-assigned suffixes, and probed each one using aioquic.
That produced 151,685 subdomains hosted by the six providers, of which 42,330 responded to an HTTP/3 request and were labeled potentially vulnerable, with the largest counts from CloudFront (17,431), Cloudflare (12,371), and Fastly (11,606). The probe establishes only that the CDN edge responds to HTTP/3, and that no origin server outside the researchers’ own test setup was attacked.
The results are compared in the paper to CDN Judo, a 2020 study of the equivalent HTTP/2-to-HTTP/1.1 conversion at CDNs, which reported factors of roughly 44x with the static table and 166x with the dynamic table.
The mitigations put to the vendors are applied at the CDN, and are as follows –
- Cap the size of any single header field entry inserted into the QPACK dynamic table, suggested at 512 bytes
- Limit how many times one dynamic table entry can be referenced within a single stream, suggested at no more than 10
- Enforce a maximum decompressed HTTP/1.1 request size and reject anything above it before forwarding, suggested at 64KB
- Buffer the complete HTTP/3 request, both HEADERS and DATA frames, before opening a CDN-to-origin connection
- Limit the number of CDN-to-origin connections a single HTTP/3 client connection can trigger
- Time out CDN-to-origin connections independently of the client connection, suggested at 30 seconds without meaningful forwarded data
Tencent’s deployed mitigations limit the number of CDN-to-origin connections and restrict the size of headers in the dynamic table, per the disclosure section of the paper, which also records bug bounty awards of approximately $350 from Baidu and $150 from Tencent.
The same section states that the other four vendors acknowledged the disclosure and were still discussing the findings internally. The paper does not report whether the attacks were retested after Baidu and Tencent deployed their mitigations, and does not say whether the attack code or the measurement framework will be published.
The work is credited to researchers at the National University of Singapore, Fuzhou University, the University of Sheffield, and Johns Hopkins University. It is due to be presented at the Symposium on Reliable Distributed Systems in Rome from September 22 to 24, 2026.
The QPACK dynamic table was the subject of a separate flaw disclosed on July 8, when FoxIO researcher Sébastien Féry reported that roughly 260 bytes of spec-compliant QPACK traffic could crash any server running XQUIC, Alibaba’s QUIC and HTTP/3 library, which provides HTTP/3 support for the Tengine web server Alibaba runs across its cloud and CDN infrastructure.
The development comes as the OpenSSL Project, on August 13, disclosed CVE-2026-14456, a low-severity flaw in which a QUIC server queues incoming channels for unknown destination connection IDs without enforcing any limit, with a fix that “introduces a limit for pending connections,” set by default to 256.
Cloudflare, in its H1 2026 DDoS Threat Report published the same week, said the attack-vector “center of gravity shifted from botnet floods to reflection and amplification,” with DNS-based attacks accounting for 34.3% of all network-layer activity in the first half of 2026.
