"CDNs do not support end-to-end HTTP/3," the researchers wrote — and that deployment gap is the fulcrum for two denial-of-service techniques they call HTTP/3 Bandwidth Amplification (HBA) and HTTP/3 Connection Amplification (HCA).
How HTTP/3 Bandwidth Amplification (HBA) and Connection Amplification (HCA) work
HBA abuses QPACK, the HTTP/3 header‑compression format. Because HTTP/1.1 carries no equivalent compression, a CDN that speaks HTTP/3 to the browser but translates to HTTP/1.1 for the origin must expand a small index back into a full decompressed header before forwarding. That means a few bytes on the attacker’s wire can produce a much larger decompressed request at the origin.
The dynamic table variant of QPACK requires the attacker to first insert a large header into the CDN’s dynamic table, then reference that entry repeatedly with small index values. HCA instead targets connection capacity: five of six tested CDNs open an HTTP/1.1 connection to the origin as soon as they receive an HTTP/3 HEADERS frame. Because HTTP/3 multiplexes many streams over one client connection, a single attacker can trigger many backend TCP connections and then hold them open by sending DATA frames at a very low rate.
Measured amplification and vendor differences
The researchers evaluated Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly, and Tencent. They report amplification "up to 350x" against the origin; the 350x figure applies only to Alibaba, Baidu, and Tencent, which support the QPACK dynamic table. Measured maxima using the QPACK static table were:
- 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)
Attacker‑side bandwidth remained below 500 Kbps against the three CDNs supporting the dynamic table and below 5 Mbps against the rest, while measured consumption at the origin exceeded 100 Mbps throughout the researchers’ tests. The amplification factor peaked near 64 concurrent streams and then declined — a pattern the paper attributes to CPU overhead at the CDN edge, though no edge CPU measurements are presented.
On connection amplification, experiments showed that, against an Apache origin with a 300‑second timeout and a 256‑connection limit, four HTTP/3 connections each multiplexing 96 streams forced 384 backend connections. Response times for benign clients rose as high as 90 seconds on Baidu and CloudFront (both returning HTTP 504), 60 seconds on Alibaba, and 15 seconds on Fastly (returning HTTP 503). Tencent closed the client‑side connection roughly 10 seconds after a probe and returned no response. Cloudflare was the single provider not found susceptible to HCA because it buffers the complete request before opening a connection to the origin.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleScope: how many subdomains responded, and where HTTP/3 is enabled
To estimate exposure the team crawled the Tranco Top 1M list and probed CNAME and NS records against known CDN suffixes using aioquic. That process identified 151,685 subdomains hosted by the six providers; 42,330 of those responded to an HTTP/3 request and were labeled potentially vulnerable. The largest counts were CloudFront (17,431), Cloudflare (12,371), and Fastly (11,606). The probe only establishes that the CDN edge answers HTTP/3; no origin servers outside the researchers’ testbed were attacked.
The paper lists HTTP/3 as enabled by default at Cloudflare and CloudFront, but notes Cloudflare’s documentation instead describes HTTP/3 as available on all plans and provides steps to enable it; AWS documentation gives http2 as the default HTTP version for new CloudFront distributions.
Mitigations proposed, and vendor responses
All suggested mitigations are applied at the CDN side. Proposed fixes include capping the size of any single QPACK dynamic table entry (suggested 512 bytes); limiting how often one dynamic table entry can be referenced within a stream (suggested no more than 10); enforcing a maximum decompressed HTTP/1.1 request size (suggested 64 KB); buffering the complete HTTP/3 request before opening a CDN‑to‑origin connection; limiting how many CDN‑to‑origin connections a single HTTP/3 client connection can trigger; and timing out CDN‑to‑origin connections independently of the client connection (suggested 30 seconds without meaningful forwarded data).
Baidu and Tencent confirmed the reports and deployed fixes. Tencent’s deployed mitigations limit CDN‑to‑origin connections and restrict dynamic table header sizes, per the paper’s disclosure section. Baidu and Tencent issued bug bounty awards of approximately $350 and $150, respectively. The other four vendors acknowledged the disclosure and were still discussing the findings internally. No CVE identifiers have been assigned, and the paper reports no exploitation in the wild.
What this means for technologists, procurement leaders, and security teams
- Technologists and security teams: Verify whether your CDN edge responds to HTTP/3 and whether the provider buffers requests before opening origin connections; monitor origin connection counts and decompressed request sizes per connection.
- Procurement and cloud architects: Confirm default HTTP versions and configuration defaults with CDN providers — the paper notes documentation differences for Cloudflare and CloudFront — and require mitigation controls where translation to HTTP/1.1 is used.
- Security program managers: Track vendor remediation and consider whether SLAs and incident reporting cover reflection/amplification risks, given the research shows amplification with modest attacker bandwidth.
The research team, credited to the National University of Singapore, Fuzhou University, the University of Sheffield, and Johns Hopkins University, will present the work at the Symposium on Reliable Distributed Systems in Rome from September 22–24, 2026. The paper also situates the findings against related disclosures: a July 8 QPACK issue that could crash XQUIC servers, and OpenSSL’s Aug. 13 disclosure of CVE‑2026‑14456, which introduced a default limit of 256 pending QUIC connections. Cloudflare’s H1 2026 DDoS report cited a shift toward reflection and amplification vectors, noting DNS‑based attacks made up 34.3% of network‑layer activity in the first half of 2026.
Which CDNs will adopt the proposed mitigations, how quickly they will roll them out, and whether the attacks scale beyond the researchers’ capped experiments remain the next concrete questions on the table.
https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html
