Researchers disclosed two denial-of-service attacks dubbed 'CDN Tsunami' that exploit how major CDNs translate HTTP/3 client traffic into HTTP/1.1 requests forwarded to origin servers. The attack achieves up to 350x amplification of low-bandwidth request streams against origin servers. The vulnerability was evaluated against major CDN providers including Alibaba and Baidu. The attack abuses the protocol translation layer inherent in CDN architectures, allowing attackers to generate disproportionately large traffic volumes at the origin with minimal effort. This represents a significant threat to websites relying on CDNs for traffic management and DDoS protection. The findings highlight a systemic weakness in how CDNs handle HTTP/3 to HTTP/1.1 conversion, potentially affecting a wide range of CDN-dependent services globally.
CDN Tsunami comprises two DoS attack techniques — HTTP/3 Bandwidth Amplification (HBA) and HTTP/3 Connection Amplification (HCA) — that exploit the protocol translation gap in CDNs that accept HTTP/3 from clients but forward requests to origin servers using only HTTP/1.1. HBA leverages QPACK header compression: attackers send compressed HTTP/3 requests using small QPACK index references, which the CDN must decompress into full raw HTTP/1.1 headers before forwarding to the origin. This results in massive bandwidth amplification. Using the QPACK dynamic table (supported by Alibaba, Baidu, Tencent), the attacker first sends a large header to populate the table, then repeatedly references it with tiny index values, achieving up to 350x amplification. Attacker-side bandwidth was below 500 Kbps (dynamic table) or below 5 Mbps (static table), while origin-side consumption exceeded 100 Mbps. Static table amplification factors: Baidu 66.06x, Alibaba 65.8x, Tencent 54.08x, CloudFront 51.2x, Cloudflare 48.27x, Fastly 36.41x. HCA exploits HTTP/3 stream multiplexing: five of six CDNs open a backend HTTP/1.1 TCP connection to the origin upon receiving just the HTTP/3 HEADERS frame, before the request body arrives. Each HTTP/3 stream triggers its own backend TCP connection. The attacker sends DATA frames at a very low rate to keep streams — and thus backend connections — open indefinitely. Against an Apache server with 300-second timeout and 256-connection limit, 4 HTTP/3 connections multiplexing 96 streams each forced 384 backend TCP connections. Response times for legitimate users reached 60–90 seconds, resulting in HTTP 504 and 503 errors. Amplification peaks near 64 concurrent streams then declines, attributed to CDN edge CPU overhead. Cloudflare is immune to HCA because it buffers the complete request before opening a backend connection. The attack was tested against Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly, and Tencent. 42,330 potentially vulnerable subdomains were identified from the Tranco Top 1M list. No CVE assigned and no in-the-wild exploitation reported.
Mitigations are applied at the CDN layer, not the origin server. Recommended and deployed mitigations include: 1. Cap the size of any single header field entry inserted into the QPACK dynamic table (suggested maximum: 512 bytes). 2. Limit how many times one dynamic table entry can be referenced within a single stream (suggested maximum: 10 references). 3. Enforce a maximum decompressed HTTP/1.1 request size and reject requests exceeding it before forwarding to origin (suggested limit: 64KB). 4. Buffer the complete HTTP/3 request (both HEADERS and DATA frames) before opening a CDN-to-origin connection (Cloudflare already does this, making it immune to HCA). 5. Limit the number of CDN-to-origin TCP connections a single HTTP/3 client connection can trigger. 6. Time out CDN-to-origin connections independently of the client connection (suggested: 30 seconds without meaningful forwarded data). Baidu and Tencent have confirmed and deployed fixes. Tencent specifically limits CDN-to-origin connections and restricts dynamic table header sizes. Alibaba, Cloudflare, CloudFront, and Fastly acknowledged the disclosure and were still evaluating internally at time of publication. For origin server operators: consider disabling HTTP/3 at the CDN edge if not required, monitor for sudden spikes in backend connection counts or bandwidth from CDN IP ranges, and configure aggressive connection timeouts on the origin web server. Apply CVE-2026-14456 patch for OpenSSL QUIC deployments.
