Security researchers have uncovered a new family of denial-of-service (DoS) attacks that manipulate how major content delivery networks (CDNs) translate client-facing HTTP/3 traffic into HTTP/1.1 when passing requests on to origin servers. The vulnerability—dubbed CDN Tsunami—can amplify a modest assault into a massive overload, with bandwidth multiplied by as much as 350×. The affected CDNs include Alibaba, Baidu, Amazon CloudFront, Fastly, Tencent, and Cloudflare. ([thehackernews.com](https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html))
How the Attack Works: Two Distinct Amplification Vectors
The researchers describe two specific techniques: HTTP/3 Bandwidth Amplification (HBA) and HTTP/3 Connection Amplification (HCA). Both exploit a mismatch between HTTP versions—CDNs accept HTTP/3 from users, but often forward traffic to origin servers using HTTP/1.1. ([thehackernews.com](https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html))
In HBA, attackers take advantage of QPACK, the header-compression system used in HTTP/3. Because HTTP/3 allows compressed headers via QPACK—and HTTP/1.1 does not—the CDN must decompress small indexed representations into full, raw header data. This enables an attacker to send minimal data yet force the origin server to handle a much larger payload. In cases where CDNs support QPACK’s dynamic table feature (notably Alibaba, Baidu, and Tencent), amplification ratios exceeded 350×. For others without dynamic table support (like CloudFront, Cloudflare, and Fastly), static tables still produced amplifications ranging between ~36× to ~51×. ([thehackernews.com](https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html))
HCA, on the other hand, stresses connection limits. Five of the six CDNs open backend HTTP/1.1 connections once the HTTP/3 HEADERS frame arrives—each stream multiplexed over one client-side HTTP/3 connection translates into its own backend TCP connection. By sending payloads slowly, attackers can keep these origin connections open without completing requests—effectively tying up resources and exceeding connection limits. For example, one test with an Apache origin server configured with a 300-second timeout and a 256-connection cap showed that just 4 HTTP/3 connections, each with 96 streams, pushed 384 backend connections. ([thehackernews.com](https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html))
Scope & Impact
Tests revealed amplified traffic at origin servers frequently surpassing 100 Mbps despite attackers keeping upstream usage under 500 Kbps (for CDNs with dynamic table support) or under 5 Mbps otherwise. Response times deteriorated significantly—some benign clients saw waits of up to 90 seconds, accompanied by HTTP 504 or 503 errors on Alibaba, Baidu, and CloudFront. Fastly showed 15-second delays. Tencent implemented defenses that closed connections roughly 10 seconds after detecting misuse. ([thehackernews.com](https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html))
Vulnerability scans of Top-1M domains found over 150,000 subdomains using the six CDNs; around 42,000 responded to HTTP/3 and are considered potentially exposed. CloudFront led the pack with nearly 17,500 such domains, followed by Cloudflare and Fastly. ([thehackernews.com](https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html))
So far, no active exploitation has been documented, and no CVE identifiers have been assigned. Baidu and Tencent have acknowledged the issue and rolled out mitigations. The study is set to be presented at the Symposium on Reliable Distributed Systems in Rome this September. ([thehackernews.com](https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html))
Proposed Mitigations
The research team recommends several fixes, all to be implemented at the CDN layer rather than requiring origin changes. Suggestions include:
- Limit size of any field inserted into the QPACK dynamic table (e.g. max 512 bytes).
- Restrict how many times one dynamic table entry can be referenced per stream (e.g. ≤10).
- Enforce maximum decompressed HTTP/1.1 request size (e.g. drop requests above 64 KB before forwarding).
- Buffer full HTTP/3 requests—including HEADERS and DATA—before opening backend connections.
- Limit number of CDN-to-origin connections per client-side HTTP/3 connection.
- Implement timeouts for backend connections independent of the client, recommended ~30 seconds without meaningful data. ([thehackernews.com](https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html))
Tencent has already limited dynamic table entry sizes and capped the number of CDN-to-origin connections. Baidu has also deployed some mitigation. The remaining providers have acknowledged the disclosure and are evaluating fixes. ([thehackernews.com](https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html))
The researchers behind this work come from National University of Singapore, Fuzhou University, University of Sheffield, and Johns Hopkins University. ([thehackernews.com](https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html))
Analysis: CDN Tsunami highlights a growing gap in how modern web infrastructure handles newer protocols like HTTP/3. The issue underscores one of HTTP/3’s strengths—header compression—also being a risk when paired with backward-compatible layers. As more traffic shifts to HTTP/3, these conversion-side channels become increasingly critical. CDNs must move quickly to patch these mismatches or risk a new breed of low-cost, high-impact DoS attacks. Web operators should monitor CDN behavior closely, verify HTTP/3 support settings, and audit origin server impacts—what was once an edge issue is shaping up to be a core internet risk.
