CDN Tsunami: the protocol translation you pay for is the amplifier

Researchers have disclosed two denial-of-service techniques, collectively named CDN Tsunami, that abuse how major content delivery networks convert client-facing HTTP/3 traffic into HTTP/1.1 requests for the sites behind them, amplifying a low-bandwidth request stream by up to 350x against the origin ^[1]. The amplifier is the translation service the customer is buying, and the researchers say every mitigation they propose is applied at the CDN rather than at the origin website ^[2].

The work was evaluated against Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly and Tencent ^[3]. All six were susceptible to the bandwidth variant; five were susceptible to the connection variant, with Cloudflare unaffected there because it buffers the complete request before opening a connection to the origin ^[4]. Both techniques rest on the same gap: the CDN speaks HTTP/3 to the browser but only HTTP/1.1 to the origin, a mismatch the team attributes to the fact that "CDNs do not support end-to-end HTTP/3" ^[5].

HTTP/3 Bandwidth Amplification (HBA) uses QPACK header compression. HTTP/1.1 has no equivalent, so the CDN expands each small index value back into a full raw header before forwarding, and a request costing the attacker a few bytes costs the origin the decompressed size ^[6]. Attacker-side bandwidth stayed below 500 Kbps against the three CDNs supporting the QPACK dynamic table and below 5 Mbps against the rest, while measured origin consumption exceeded 100 Mbps throughout ^[7] - a ratio on the wire of better than 200 to 1 in the first case ^[8]. Static-table maxima were Baidu 66.06x, Alibaba 65.8x, Tencent 54.08x, CloudFront 51.2x, Cloudflare 48.27x and Fastly 36.41x ^[9]. The 350x headline figure applies only to Alibaba, Baidu and Tencent, the three that support the dynamic table, measured at roughly 64 concurrent streams ^[10]; each advertises a 4KB table with a 3,072-byte maximum entry ^[11].

HTTP/3 Connection Amplification (HCA) goes after connection capacity. Five of the six CDNs open a backend HTTP/1.1 connection as soon as the HTTP/3 HEADERS frame arrives, before the body, and each multiplexed stream triggers its own backend TCP connection; slow DATA frames then hold those connections open as incomplete ^[12]. Against an Apache origin with a 300-second timeout and a 256-connection limit, four HTTP/3 connections of 96 streams each forced 384 backend connections ^[13], about 1.5 times the configured ceiling ^[14]. Fastly needed 48 connections of 8 streams because it caps backend connections at 10 per HTTP/3 connection ^[15] - the same 384 streams by another route ^[16]. Benign client response times reached 60 seconds on Alibaba and up to 90 seconds on Baidu and CloudFront, both returning 504 ^[17]; Fastly rose to 15 seconds with a 503 ^[18], and Tencent closed the client connection after roughly 10 seconds with no response ^[19].

Scope matters. No CVEs have been assigned and no in-the-wild exploitation is reported ^[20]. The experiments were self-bounded, with the origin capped at 100 Mbps and the attacker at 30 Mbps ^[21]. The precondition is a site on one of the six providers with HTTP/3 at the edge and no configuration change by the site ^[22]. The paper lists HTTP/3 as on by default at Cloudflare and CloudFront ^[23], but Cloudflare's documentation describes it as available on all plans with steps to enable it ^[24], and AWS documentation gives http2 as the default for new CloudFront distributions ^[25]. Check what your own edge is actually negotiating rather than trusting the default.

Watch which providers ship. Baidu and Tencent confirmed the reports and deployed the proposed fixes ^[26]; that leaves the other four in the tested set without confirmed fixes ^[27]. Watch also for any move toward end-to-end HTTP/3 to the origin, which would close the gap rather than patch it ^[5], and for CVE assignment, which is what most vulnerability management pipelines actually key on ^[20].