CDN Tsunami: Critical HTTP/3 to HTTP/1.1 Protocol Translation Vulnerability Triggers Up to 350x DoS Amplification Across Major CDN Providers

Executive Summary

A new class of Denial-of-Service (DoS) attacks, collectively named CDN Tsunami, exploits the protocol translation gap in major Content Delivery Networks (CDNs) between HTTP/3 (QUIC) at the edge and HTTP/1.1 to the origin server. This attack enables adversaries to amplify a small volume of HTTP/3 traffic into a massive HTTP/1.1 request stream, achieving up to 350x amplification against the origin. The vulnerability affects six major CDN providers: Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly, and Tencent. There is currently no CVE assigned, and no exploitation in the wild has been reported as of August 2026. Mitigations have been deployed by Baidu and Tencent, while other vendors have acknowledged the issue but have not yet remediated. Over 42,000 subdomains in the Tranco Top 1M are potentially vulnerable.

Technical Information

The CDN Tsunami attack leverages the protocol translation gap between HTTP/3 (QUIC) at the CDN edge and HTTP/1.1 to the origin. Two primary attack variants have been identified: HTTP/3 Bandwidth Amplification (HBA) and HTTP/3 Connection Amplification (HCA).

The HBA variant abuses the QPACK header compression mechanism in HTTP/3. Attackers send small, highly compressed HTTP/3 requests to the CDN edge, which decompresses these headers and forwards them as large HTTP/1.1 requests to the origin. The dynamic table variant of this attack involves inserting a large header into the QPACK dynamic table and repeatedly referencing it with small indices, causing massive expansion. Amplification factors reach up to 350x for Alibaba, Baidu, and Tencent (dynamic table, 64 streams), and between 36x and 66x for other providers using static tables. The attacker requires less than 500 Kbps bandwidth for the dynamic table variant and less than 5 Mbps for the static table variant, while the origin can be forced to consume over 100 Mbps.

The HCA variant targets connection exhaustion at the origin. Most CDNs open an HTTP/1.1 connection to the origin as soon as they receive an HTTP/3 HEADERS frame, even before the request body arrives. HTTP/3 multiplexing allows a single client connection to carry multiple streams, each triggering a backend TCP connection. Attackers can send DATA frames at a very low rate, keeping connections open and exhausting the origin’s connection pool. For example, four HTTP/3 connections, each with 96 streams, can force 384 backend connections against a 256-connection Apache server, resulting in severe service degradation.

All six tested CDNs are vulnerable to HBA, while five (all except Cloudflare) are vulnerable to HCA. Cloudflare is immune to HCA due to buffering the complete request before opening a backend connection. Exposure analysis shows that 151,685 subdomains are hosted by these CDNs, with 42,330 confirmed HTTP/3-enabled and potentially vulnerable.

The root cause of this vulnerability is the heterogeneous protocol deployment: CDNs support HTTP/3 at the edge but only HTTP/1.1 to the origin, creating a protocol translation gap. QPACK header compression in HTTP/3 is not matched by HTTP/1.1, leading to decompression and amplification at the CDN.

Exploitation in the Wild

No exploitation in the wild has been reported as of August 2026. There is no CVE assigned for this vulnerability, and it is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Bug bounties have been awarded by Baidu ($350) and Tencent ($150) for responsible disclosure. Baidu and Tencent have deployed mitigations, while other vendors have acknowledged the issue but have not yet remediated.

APT Groups using this vulnerability

There is no public attribution of this vulnerability to any Advanced Persistent Threat (APT) group, and no evidence of exploitation in the wild as of this report.

Affected Product Versions

All tested CDN products are affected in their default configurations as of July 2026, specifically when the CDN supports HTTP/3 (QUIC) on the client-to-edge connection and uses HTTP/1.1 for edge-to-origin (backend) connections. HTTP/3 is enabled by default for Cloudflare and CloudFront, and configurable for others. The attack is protocol and configuration dependent, not tied to a specific software version, but to the CDN’s HTTP/3-to-HTTP/1.1 translation architecture as deployed in production as of July/August 2026.

The affected products are Alibaba, Baidu, Cloudflare, CloudFront, Fastly, and Tencent in their current production deployments.

Workaround and Mitigation

All effective mitigations must be implemented by the CDN provider. Recommended strategies include capping QPACK dynamic table entry size (suggested: 512 bytes), limiting references to a dynamic table entry per stream (suggested: max 10), enforcing a maximum decompressed HTTP/1.1 request size (suggested: 64KB), buffering complete HTTP/3 requests before opening backend connections (as implemented by Cloudflare), limiting the number of backend connections per client HTTP/3 connection (as implemented by Fastly), and timing out backend connections independently of the client connection (suggested: 30 seconds without meaningful data). There is no effective origin-side mitigation.

Indicators of Compromise

The following indicators are point-in-time and should be validated before enforcement. They are extracted from public research and documentation sources related to the CDN Tsunami attack.

References

Primary Research Paper: arXiv:2607.26589v1 - CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks News Coverage: The Hacker News: CDN Tsunami Attack Abuses HTTP/3 Translation for Up to 350x DoS Amplification Cloudflare HTTP/3 Documentation: https://developers.cloudflare.com/speed/optimization/protocol/http3/ RFC 9114 (HTTP/3): https://datatracker.ietf.org/doc/html/rfc9114 RFC 9204 (QPACK): https://datatracker.ietf.org/doc/html/rfc9204 Related research: CDN Judo (HTTP/2-to-HTTP/1.1 amplification) RangeAmp (HTTP Range Request amplification)

Rescana is here for you

Rescana provides a comprehensive Third-Party Risk Management (TPRM) platform, empowering organizations to continuously monitor, assess, and manage cyber risk across their entire supply chain. Our platform delivers actionable intelligence, automated workflows, and deep visibility into vendor security posture, helping you stay ahead of emerging threats. We are happy to answer any questions at info@rescana.com.