Your edge speaks HTTP/3, your origin speaks HTTP/1.1: that gap is now a DoS primitive

A paper posted to arXiv, "CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks", presents what its authors call the first study of denial-of-service attacks against HTTP/3 as deployed at CDNs ^[3]. The mechanism is not a protocol bug but a translation gap: when the edge terminates HTTP/3 and the origin still speaks HTTP/1.1, an attacker can send a small amount of traffic to the CDN and have it expanded into a large amount of traffic from the CDN to the origin ^[4].

The paper describes two variants, aimed at two different origin resources ^[1]. HTTP/3 Bandwidth Amplification abuses QPACK: small index values on the wire are decoded into large raw HTTP headers when the edge rewrites the request for HTTP/1.1 ^[5]. HTTP/3 Connection Amplification works the other way, sending DATA frames slowly to control how long the CDN-to-origin connection is held open, exhausting the origin's available connection resources until legitimate requests are blocked ^[6]. Bytes and sockets are independent budgets, so the two techniques press on separate limits rather than the same one ^[7].

The scale claim is a measurement, not a projection. Scanning the Tranco Top 1M domain list, the authors identify 42,330 subdomains they describe as potentially vulnerable ^[8] - potentially, because external observation of a version mismatch is not the same as a confirmed successful attack against each host. The authors say they disclosed to affected CDN vendors, and that two vendors have acknowledged the vulnerabilities with bounties and deployed the authors' mitigations ^[2]. Which vendors, and how many remain unfixed, the abstract does not say.

Context matters for how much of the web this describes. HTTP/3 was standardized in RFC 9114 and RFC 9204, and the paper cites third-party figures putting support at 35.2% of websites, along with most CDN services ^[9]. It also cites measurements showing over 55% of the Top 10K and more than 40% of the Top 1M websites sitting behind CDNs ^[10]. The overlap of those two populations is where the primitive lives, and it grows every time an edge is upgraded without touching the origin.

This is a family, not a one-off. The paper points to prior work in the same shape: Guo et al. built an amplification attack out of HTTP/2-to-HTTP/1.1 conversion ^[11], Li et al. used HTTP Range Requests to turn a small request into a large one at the origin ^[12], and Triukose et al. exhausted origin bandwidth by disconnecting the client-CDN connection quickly ^[13]. The authors' own framing is that most of those attacks are widely known and already defended against by providers ^[14], which is precisely why a new protocol version at the edge reopens the category. Each conversion layer is an opportunity to make the origin pay more than the client did.

The practical read for operators is that origin capacity planning based on client-side traffic volume is wrong wherever the edge changes protocol version. What to watch: whether the vendors who have not acknowledged anything publish mitigations, whether the disclosed fixes are edge-side normalization or origin-side rate control, and, closer to home, whether your own edge is negotiating HTTP/3 with clients while pooling HTTP/1.1 to an origin whose connection limit nobody has revisited since the upgrade.