Cybersecurity researchers have disclosed two denial-of-service (DoS) attacks that take advantage of how major CDNs handle HTTP/3. The core issue is a translation gap: while HTTP/3 is spoken to the visitor at the edge, the CDN sends HTTP/1.1 requests to the website behind it. This mismatch can amplify an attacker’s low-bandwidth traffic into a much larger load on the origin server.
The attacks were evaluated together under the name CDN Tsunami. In controlled testing, the researchers reported amplification factors that in some cases reached up to 350x, depending on the specific CDN behavior and the technique used. Importantly, the work describes mitigations that are implemented at the CDN layer rather than requiring changes on the website itself.
What makes CDN Tsunami possible?
Both techniques rely on the same structural deployment gap. The CDN accepts client-facing HTTP/3 connections, but it does not provide true end-to-end HTTP/3 connectivity to the origin. Instead, the CDN converts the request into an HTTP/1.1 message before forwarding it.
That conversion has consequences:
- Small inputs from the client can require larger reconstructed work at the CDN edge when transforming headers for HTTP/1.1.
- Connection handling differences can cause the CDN to open and keep multiple backend connections, inflating load beyond what the attacker actually transmits.
As a result, the attack’s “cost” to the attacker stays relatively low while the origin can see sustained high bandwidth or many concurrent connections.
The two CDN Tsunami attacks: HBA and HCA
The researchers describe two named techniques: HTTP/3 Bandwidth Amplification (HBA) and HTTP/3 Connection Amplification (HCA). They target different resource constraints—bandwidth in one case and connection capacity in the other.
1) HTTP/3 Bandwidth Amplification (HBA)
HBA focuses on header compression. HTTP/3 introduces QPACK, a header compression mechanism. But HTTP/1.1 has no direct equivalent. Therefore, when the CDN receives compact header information from the client over HTTP/3, it must expand or reconstruct the full raw header form before sending the request to the origin.
In practical terms, a request that costs an attacker only a few bytes on the wire may translate into a much larger decompressed header payload at the origin-facing side. The researchers observed that origin-side bandwidth exceeded 100 Mbps throughout testing, while the attacker’s bandwidth remained far lower.
HBA has another key ingredient: it depends on the CDN supporting QPACK’s dynamic table. The dynamic-table variant was supported by three providers—Alibaba, Baidu, and Tencent—each advertising a 4KB dynamic table with a maximum entry size of 3,072 bytes.
Dynamic table results
For the QPACK dynamic table version, the measured maximum amplification factors were:
- Baidu: 66.06x (dynamic table supported)
- Alibaba: 65.8x (dynamic table supported)
- Tencent: 54.08x (dynamic table supported)
The researchers also measured variants using the QPACK static table (where dynamic-table features are not involved). Reported amplification factors included:
- Amazon CloudFront: 51.2x (no dynamic table support)
- Cloudflare: 48.27x (no dynamic table support)
- Fastly: 36.41x (no dynamic table support)
One notable requirement is the attacker’s initial step: first send a larger header in an HTTP/3 request so the CDN inserts it into the dynamic table, then repeatedly reference the stored entry using small index values.
2) HTTP/3 Connection Amplification (HCA)
HCA targets connection capacity rather than bandwidth. The researchers found behavior differences across CDNs in how they start backend communication. For five of the six providers tested, the CDN opens an HTTP/1.1 connection to the origin immediately after receiving the HTTP/3 HEADERS frame—before the request body arrives.
Because HTTP/3 supports multiplexing, a single client connection can carry multiple streams. If each stream triggers its own backend TCP connection, then sending HTTP/3 DATA frames at a very low rate can keep many backend connections open. Meanwhile, the CDN continues treating the request as incomplete.
Cloudflare was different in a way that mattered. The researchers reported Cloudflare as unaffected by the connection variant because it buffers the complete request before opening the origin connection.
Connection amplification behavior observed
To illustrate the effect, the paper discusses testing against an Apache server configured with a 300-second timeout and a 256-connection limit. In one described scenario, four HTTP/3 connections—each multiplexing 96 streams—forced 384 backend connections on the origin. Fastly required a different connection pattern due to a backend connection cap: the researchers observed 48 connections using 8 streams per HTTP/3 connection because the provider limits backend connections to 10 per HTTP/3 connection.
Response behavior also varied. A benign client request reached up to 60–90 seconds depending on the CDN and returned errors such as HTTP 504 Gateway Timeout on some providers. Fastly showed faster degradation (around 15 seconds) and returned HTTP 503 Service Unavailable. Tencent closed the client-side connection roughly 10 seconds after a probe request without returning a response.
How much exposure did the researchers find?
The researchers attempted to estimate exposure by enumerating subdomains. They started with subdomains under the Tranco Top 1M list, gathered CNAME and NS records, matched those to known CDN-assigned suffix patterns, and probed candidates using aioquic.
That process resulted in 151,685 subdomains hosted by the six providers. Of these, 42,330 responded to an HTTP/3 request and were labeled potentially vulnerable. The largest counts were reported for:
- Amazon CloudFront: 17,431
- Cloudflare: 12,371
- Fastly: 11,606
However, the probing step mainly indicates that the CDN edge responds to HTTP/3. The researchers clarified that their experiments did not attack origins outside their own test setup.
Mitigations were implemented at the CDN
The disclosure states that each suggested mitigation is applied at the CDN rather than on the origin website. That distinction is important for operators who otherwise might assume they need to change application code or server configurations.
Among the proposed defenses were measures aimed at limiting how much amplification the CDN can produce:
- Cap the size of any single QPACK dynamic table header entry (suggested at 512 bytes)
- Limit references to one dynamic table entry within a single stream (suggested at no more than 10)
- Enforce a maximum decompressed HTTP/1.1 request size and reject larger requests (suggested at 64KB)
- Buffer the complete HTTP/3 request (both HEADERS and DATA frames) before opening a CDN-to-origin connection
- Limit backend connection triggers per client HTTP/3 connection
- Time out CDN-to-origin connections independently from the client connection (suggested at 30 seconds without meaningful forwarded data)
The paper also notes that Tencent’s deployed mitigations include limiting backend connections and restricting QPACK dynamic-table header sizes. For Baidu and Tencent, the researchers say fixes were deployed after confirmation. For the other four vendors, the paper records acknowledgement of the disclosure and ongoing internal discussion.
No CVEs reported, and no real-world exploitation
In the reported disclosure, the researchers mention that no CVE identifiers were assigned. They also state there is no report of exploitation “in the wild” at the time of writing.
They do, however, compare their findings to a prior line of research related to CDN translation issues for HTTP/2 to HTTP/1.1, where amplification factors were also observed. That earlier work reported figures roughly in the range of tens of times for static-table cases and much higher for dynamic-table scenarios.
Related QPACK and QUIC security context
The researchers’ discussion of QPACK connects to other QUIC and HTTP/3 ecosystem issues. The same QPACK dynamic table concept has been associated with a separate flaw reported earlier, where certain QPACK traffic could crash servers using QUIC and HTTP/3 implementations. Additionally, OpenSSL disclosed a QUIC-related issue involving queued channels for unknown destination connection IDs and an associated fix that introduces a limit for pending connections.
While these items are not described as part of CDN Tsunami itself, they underline that protocol extensions like QPACK and QUIC frequently introduce new parsing and state-management requirements—areas where safety checks and robust limits matter.
Bottom line for website operators using CDNs
CDN Tsunami highlights a practical DoS risk that emerges from the way some CDNs translate HTTP/3 into HTTP/1.1 toward the origin. In testing, the translation gap enabled both bandwidth and connection amplification, reaching up to around 350x in certain conditions.
For operators, the key takeaway is that mitigations are designed to live at the CDN layer: limiting QPACK-related decompression and buffering requests before opening backend connections can reduce amplification. If your site uses a CDN and relies on HTTP/3 at the edge, it’s worth verifying that your provider has adopted appropriate protections and updated configurations.
The researchers plan to present the work at the Symposium on Reliable Distributed Systems in Rome from September 22 to 24, 2026.
Source: https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html
