CDN Tsunami: When HTTP/3 Efficiency Becomes a DDoS Amplifier

HTTP/3 was built to make the web faster and more resilient. By replacing TCP with QUIC, it reduces connection-establishment overhead, handles packet loss more gracefully across concurrent streams, and is particularly well suited to mobile and less reliable network environments. Its QPACK header-compression mechanism further reduces the amount of data that needs to travel across the network.

‍

These improvements are significant, and HTTP/3 is rapidly becoming mainstream. HTTP Archive measurements from June 2026 show HTTP/3 support on 40.7% of desktop requests and 42.2% of mobile requests, while W3Techs reports HTTP/3 on 40.3% of websites in August 2026. Yet the Internet has not transitioned to HTTP/3 uniformly. In many deployments, HTTP/3 ends at a CDN or reverse proxy while communication with the application origin continues over HTTP/1.1 or HTTP/2.

‍

A recently published paper, CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks, shows why that distinction matters. The researchers demonstrate that the efficiency difference between the two sides of a CDN can itself become a source of DDoS amplification. The lesson is not that HTTP/3 is insecure; rather, whenever an intermediary translates between protocols with very different resource characteristics, the translation boundary must itself become part of the security model.

‍

HTTP/3 at the edge does not necessarily mean HTTP/3 at the origin

When a browser establishes an HTTP/3 connection with a website, it is easy to imagine that HTTP/3 continues all the way to the web server hosting the application. That is certainly possible today, but it is far from universal. A common CDN architecture terminates the client’s QUIC connection, processes the HTTP request, and creates a separate connection toward the customer’s origin using an earlier version of HTTP.

‍

‍

Cloudflare provides a useful illustration. Its current HTTP/3 documentation states that HTTP/3 is supported between users and the Cloudflare edge, while HTTP/3 connectivity from Cloudflare to the origin is not yet supported. There are good operational reasons for this model: CDNs can deploy new protocols at their own edge networks without requiring customers to simultaneously upgrade web servers, application stacks, firewalls and load balancers.

‍

The trade-off is protocol asymmetry. A request optimized for efficient transmission over HTTP/3 must eventually be reconstructed into a different representation before it can be forwarded to an HTTP/1.1 origin. CDN Tsunami demonstrates that an attacker can deliberately exploit this difference.

‍

When compression becomes bandwidth amplification

The first attack described by the researchers is HTTP/3 Bandwidth Amplification, or HBA. HTTP/3 uses QPACK to compress HTTP headers. Rather than repeatedly transmitting identical or lengthy header fields in full, QPACK allows them to be represented more efficiently, including by referencing entries in a compression table. Under normal circumstances, this is exactly what we want: fewer bytes are transmitted while preserving the same HTTP semantics.

‍

The situation changes when the CDN must forward the request to an HTTP/1.1 server. HTTP/1.1 does not understand QPACK, so the CDN must decompress and reconstruct those headers before sending them downstream. The amount of data arriving from the attacker can therefore be substantially smaller than the amount of data the CDN ultimately transmits toward the origin.

‍

‍

The researchers measured amplification ratios ranging from several tens of times using QPACK’s static table to approximately 350 times in experiments involving its dynamic table. In their controlled test environment, less than 500 Kbps of attacker traffic could create sufficient downstream traffic to overwhelm a 100 Mbps origin connection. Rather than supplying all of the attack bandwidth themselves, attackers persuade a CDN to generate much of it on their behalf.

‍

Connection efficiency can be amplified too

Bandwidth is only one form of resource consumption. CDN Tsunami’s second technique, HTTP/3 Connection Amplification (HCA), targets backend connections instead. QUIC is designed to multiplex many independent HTTP/3 streams efficiently over a single connection. This avoids the overhead associated with repeatedly creating TCP connections and allows unrelated streams to progress independently when packets are lost.

‍

The problem emerges when those frontend streams are mapped inefficiently to backend HTTP/1.1 connections. A small number of QUIC connections containing many streams can potentially cause a CDN to establish a much larger number of TCP connections toward the origin. The research found that several tested implementations began allocating backend connections after receiving HTTP/3 request headers rather than waiting for the entire request to arrive, allowing an attacker to initiate many streams and then slowly deliver the remaining data.

‍

‍

The amplification in this case is not measured in gigabits per second. It is measured in connection tables, sockets, workers, memory and ultimately the number of legitimate users that the origin is still capable of serving. This matters because DDoS has never been exclusively a bandwidth problem; any sufficiently constrained resource can become the target.

‍

The CDN becomes the amplifier

Traditional amplification attacks tend to follow a familiar pattern: an attacker sends a small request to an intermediary such as a misconfigured DNS service, which then generates a much larger response toward the victim. CDN Tsunami presents a different problem. The intermediary is not an obscure or improperly exposed service; it is a legitimate CDN that the victim has intentionally placed in front of its application.

‍

The resulting traffic reaching the origin can therefore appear legitimate. It comes from trusted CDN infrastructure, uses valid HTTP, and may even originate from IP ranges that the customer’s firewall has specifically allowlisted. In many CDN deployments, allowing only CDN addresses to reach an origin is itself considered good security practice. That means conventional questions such as “Where did this traffic come from?” become less useful. A more important question is: “How much downstream work did this apparently small frontend request cause?”

‍

‍

Security needs to account for both sides of the proxy

Application-layer DDoS protection traditionally relies on signals such as request rates, connection rates, source reputation, URL behaviour, session characteristics and deviations from established traffic baselines. All remain useful, but protocol translation introduces another relationship worth monitoring: frontend-to-backend resource amplification.

‍

A 2 KB request arriving at a proxy that produces a 100 KB request toward the origin is not necessarily alarming when either side is examined independently. A 50-to-1 expansion ratio, however, deserves attention. The same applies to connections: one QUIC connection carrying dozens or hundreds of HTTP/3 streams may be perfectly normal, but if those streams result in excessive backend connections, the frontend connection count alone provides an incomplete view of the risk.

‍

Modern proxies and application-protection platforms therefore need visibility into these ratios. Relevant controls include maximum decompressed header sizes, QPACK limits, HTTP/3 stream concurrency controls, constraints on backend connection fan-out, request validation before expensive backend resources are allocated, appropriate stream and connection timeouts, and detection of abnormal protocol-conversion ratios. These are often described as HTTP/3 mitigations, but the broader principle is resource governance: how much downstream work should one unit of upstream activity be permitted to create?

‍

HTTP/3 is not the vulnerability

It is important not to misinterpret the research as an indictment of HTTP/3 itself. QPACK is doing what compression is intended to do, QUIC is doing what multiplexing is intended to do, and HTTP/3’s ability to move more information with less connection and transport overhead is a feature, not a defect.

‍

The vulnerability arises when these efficiencies are allowed to translate into disproportionate resource consumption elsewhere in the delivery chain. The answer is therefore not to stop adopting newer protocols. The better answer is to treat protocol conversion as a security boundary in its own right.

‍

HTTP/3 adoption is growing, but the transition is uneven

HTTP/3 is now sufficiently widespread that supporting it is becoming an increasingly important consideration for CDN, application-delivery and WAAP providers. At the same time, published HTTP/3 adoption figures should not be confused with the proportion of origin servers that natively terminate HTTP/3. A significant amount of today’s HTTP/3 traffic terminates at Internet-facing infrastructure operated by CDNs and reverse proxies, while applications behind that edge continue to run across a mixture of HTTP/1.1, HTTP/2 and increasingly HTTP/3-capable servers.

‍

This heterogeneous environment is unlikely to disappear quickly. Enterprises replace backend infrastructure far more slowly than browsers and hyperscale edge networks adopt new transport technologies. Protocol translation will therefore remain a normal part of Internet architecture for the foreseeable future. The question for security providers is not whether translation should exist, but whether its resource implications are properly understood and constrained.

‍

A measured approach to HTTP/3

Nexusguard’s Application Protection service does not currently terminate client-side HTTP/3 connections. Clients instead negotiate a supported HTTP version, including HTTP/2. Consequently, the specific HTTP/3-to-HTTP/1.1 conversion path exploited by CDN Tsunami is not present in our current Application Protection architecture.

‍

This should not be interpreted as an argument against HTTP/3. The performance advantages of QUIC and HTTP/3 are clear, and HTTP/3 support is an area we continue to evaluate. However, implementing it securely requires more than enabling QUIC at the frontend and translating requests into an existing backend protocol. The CDN Tsunami research reinforces the need to consider decompressed header expansion, stream concurrency, backend connection allocation, frontend-to-backend fan-out and resource-amplification ratios as part of the design itself.

‍

There is also an important distinction between protecting QUIC traffic and providing HTTP/3 application protection. Network-layer DDoS systems can detect and mitigate many volumetric and transport-level attacks involving UDP and QUIC without terminating the HTTP/3 session. Understanding HTTP requests, QPACK behaviour and application-layer stream semantics, however, requires a deeper level of HTTP/3 awareness. As adoption grows, both capabilities will increasingly matter.

‍

The bigger lesson from CDN Tsunami

Internet infrastructure has always evolved by becoming more efficient. Compression reduces bandwidth, multiplexing reduces connection overhead, persistent connections reduce repeated handshakes, and caching reduces origin workload. Each generation allows more useful work to be accomplished with fewer resources. Attackers look at the same efficiencies from the opposite direction: they search for situations in which a small amount of their own effort can cause somebody else’s infrastructure to perform a disproportionate amount of work.

‍

CDN Tsunami is an especially interesting example because none of the individual technologies needs to be fundamentally broken. HTTP/3 can work correctly, QPACK can work correctly, HTTP/1.1 can work correctly, and the CDN can successfully translate between them. Yet the relationship between these correctly functioning components can still create an amplification opportunity.

‍

That is perhaps the broader lesson for DDoS defence. Protecting modern infrastructure increasingly requires looking not only for malicious packets or excessive requests, but also for asymmetries in how work moves through a system. Whenever an intermediary can be made to do substantially more work than the party asking it to, attackers have a potential advantage. As protocols become more efficient and infrastructure becomes more interconnected, understanding those hidden amplification boundaries may prove just as important as measuring the traffic itself.

‍

Sources

‍CDN Tsunami research paper — arXiv, 29 July 2026

‍RFC 9114 — HTTP/3

‍Cloudflare HTTP/3 documentation — user-to-edge support and origin limitation

‍HTTP Archive — State of the Web, HTTP/3 support

‍W3Techs — HTTP/3 usage statistics, August 2026