Loading today’s stories
Build1 distinct publisher3 min readUpdated
A new arXiv paper describes two amplification attacks that turn a CDN's HTTP/3 front end into a pump aimed at HTTP/1.1 origins. Two CDN vendors have paid bounties and shipped the authors' mitigations.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
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 [1]. 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 [2].
The paper describes two variants, aimed at two different origin resources [3]. 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 [4]. 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 [5]. Bytes and sockets are independent budgets, so the two techniques press on separate limits rather than the same one [6].
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 [7] - 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 [8]. 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.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The authors design two attack variations, HTTP/3 Bandwidth Amplification (HBA) and HTTP/3 Connection Amplification (HCA), targeting bandwidth and the number of connections respectively.
The authors responsibly disclosed the attack details to the affected CDN vendors; so far two vendors have acknowledged their vulnerabilities with bounties and have deployed the authors' mitigations.
The paper "CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks", published on arxiv.org, presents what its authors describe as the first study of DoS attacks against HTTP/3 protocols deployed at CDNs.
The paper's key insight is that when a CDN adopts HTTP/3 but the host website uses HTTP/1.1, an adversary can use the disparity to amplify a small amount of traffic sent to the CDN over HTTP/3 into a large amount of traffic from the CDN to the host website over HTTP/1.1.
The HBA attack exploits the CDN's HTTP/3-to-HTTP/1.1 conversion, in which small QPACK index values, a feature introduced in HTTP/3, are decoded into large raw HTTP headers, producing bandwidth amplification against host websites.
The HCA attack gradually sends DATA frames to control the kept-open time of the CDN-to-website connection, exhausting all available connection resources of the host website and blocking legitimate requests.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed and internally consistent, but single-source and self-reported
The mechanism is described at protocol-feature granularity (QPACK index decoding, DATA-frame pacing), tested against six named-count CDN vendors, and quantified across the Tranco Top 1M, and two vendors paying bounties and shipping the authors' fixes is meaningful third-party corroboration of the underlying defect. Against that: the cluster contains exactly one source, an arXiv preprint with no peer review or independent replication in evidence, the vendors are unnamed, the affected subdomain count is qualified as 'potentially vulnerable', and no amplification ratio or resource-exhaustion threshold appears in the supplied text.
Large exposed population, early and partial remediation
Adoption of the preconditions is well documented: HTTP/3 is standardized and supported by 35.2% of websites and most CDNs, over 40% of the Top 1M sits behind a CDN, and the authors' own scan places 42,330 Tranco subdomains in the potentially-vulnerable bucket across 151,685 CDN-hosted subdomains. Remediation adoption is real but early, with two of six evaluated vendors having deployed mitigations and no evidence about the other four or about origin-side changes by site operators.
Slightly overstated: mechanism solid, blast radius author-estimated
The framing of a protocol-version gap as a usable DoS primitive is largely earned, because vendors paid bounties and deployed the proposed mitigations. The modest positive gap comes from headline numbers doing more work than the evidence strictly supports: 42,330 subdomains are 'potentially vulnerable' by the authors' own automated classifier rather than confirmed exploitable, the 'first study' framing is a self-asserted priority claim, and no amplification magnitude is published in the supplied text, so a reader cannot tell whether the practical impact is a nuisance or an outage.
Academic novelty and bounty incentives, self-published venue
The sole source is the researchers' own preprint, and the incentives visible in the text are the usual academic ones: establishing priority ('the first study'), branding two named attack variants, and maximizing the apparent real-world impact of a measurement study. The authors also disclose that they were paid bug bounties by two vendors, a direct financial interest in the findings being judged severe. Countervailing incentives are the responsible-disclosure process, mitigation development, and vendor anonymization, which are consistent with harm-reduction rather than pure attention-seeking. No sponsor, funder, or vendor-affiliation information is supplied, so the assessment covers only incentives evident on the page.
Moderate: mechanism trustworthy, scale and vendor status unverified
Confidence is limited mainly by source count. One publisher, no independent replication, and unnamed vendors mean the mechanics and the disclosure narrative must be taken on the authors' word, though the internal detail, the six-vendor test matrix, and the vendor bounties make the core finding credible. Scale figures and any operator-specific exposure remain unverified, which is where the residual uncertainty sits.
security
CDN Tsunami: the protocol translation you pay for is the amplifier1 distinct publisher
build
Route leak prevention moves into the protocol, and two Tier-1s are stripping the signal1 distinct publisher
science
GJ 523b gives 'Mega-Earth' a number: 23 Earth masses inside 2.5 Earth radii1 distinct publisher
security
Akrites switches on in September with 20-odd members and a one-to-10 engineer donation band1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 21, 2026