Researchers Found Six Major CDNs Vulnerable to New HTTP/3 Attacks. Two Deployed Mitigations.

Researchers have published two denial of service techniques that turn a content delivery network against the site behind it. They tested Alibaba, Baidu, Cloudflare, CloudFront, Fastly and Tencent. All six amplified an attacker’s traffic on the way to the origin server, and the researchers identified 42,330 subdomains potentially exposed.

Baidu and Tencent have deployed the researchers’ mitigations, each after paying a bounty in the low hundreds of dollars. The other four acknowledged the report and were still discussing it internally when the paper was finalized.

The site owner cannot repair the underlying CDN behavior. Every mitigation the researchers propose sits at the CDN.

Key facts

• What it is: two attacks, named HBA and HCA, that exploit the gap between the HTTP/3 a CDN speaks to browsers and the HTTP/1.1 it speaks to the origin.
• Who found it: researchers at the National University of Singapore, Fuzhou University, the University of Sheffield and Johns Hopkins, posted on 29 July and due for presentation in Rome in September.
• The spread: bandwidth amplification of 36.41x to 66.06x across the six, with a separate 350x figure that applies only to the three CDNs supporting the QPACK dynamic table.
• Connection exhaustion: five of the six, with Cloudflare the exception. During the attack, connections from CDN to origin consistently exceeded 300.
• Mitigations deployed: Baidu and Tencent. Still in internal discussion when the paper was finalized: Alibaba, Cloudflare, CloudFront and Fastly.
• Scale: the authors classified 42,330 HTTP/3-enabled subdomains behind the affected CDNs as potentially vulnerable to the amplification attacks. All six were open to HBA; HCA reached five of the six.
• Not a patch story: no CVE has been assigned, no exploitation has been reported, and site owners have nothing to update.

A Modern Front Door and an Old Back One

The whole thing rests on a deployment habit rather than a coding error. A CDN speaks HTTP/3 to the visitor, because that is what modern browsers want, and then speaks HTTP/1.1 to the website it fronts. The researchers found this held even when the origin itself supported HTTP/3, and put the persistence of the arrangement down to CDN operators seeing too little benefit in running HTTP/3 on the back leg to justify the work. It is a property of how these CDN deployments are built rather than a limitation of the sites behind them. The CDN sits in the middle translating, and the translation is where the leverage is.

The first attack, HTTP/3 Bandwidth Amplification, uses QPACK, the header compression scheme HTTP/3 introduced. It comes in two grades. Against all six CDNs the attacker works through QPACK’s static table, a fixed list of common headers both sides already hold, referring to entries by index so the request leaving the attacker stays tiny while the one the CDN reconstructs and forwards does not. Against the three that also support the dynamic table, the attacker first loads it with large headers, up to 3,072 bytes each, and the same trick goes considerably further.

The second, HTTP/3 Connection Amplification, is quieter. Instead of flooding, the attacker sends data frames slowly, controlling how long each CDN-to-origin connection stays open, and holds enough of them to exhaust the origin’s connection pool. Legitimate visitors then queue behind connections that are being kept alive on purpose.

Neither needs much from the attacker. The researchers argue that an ordinary laptop would be enough, because the point is to make someone else generate the volume; their own tests ran from a VPS in Singapore. They capped the target’s bandwidth at 100 megabits per second and their own at 30, limits they describe as self-imposed for ethical reasons rather than a ceiling on what the attack could do.

The Numbers, and Which Ones Apply to Whom

One figure from this research is circulating faster than the rest, and it does not mean what a quick read suggests.

Amplification figures are the paper’s maximums using the QPACK static table, which all six CDNs support. Alibaba, Baidu and Tencent additionally support the dynamic table, where the researchers measured up to approximately 350x, peaking at around 64 concurrent streams, which the researchers attribute to CPU overhead in QPACK decompression at the CDN edge. That 350x is the maximum of the experiment, not a level each of the three reached, and it does not apply to Cloudflare, CloudFront or Fastly.

The connection attack splits differently again. Five of the six were vulnerable, Cloudflare being the exception, and during the attack the number of open connections from CDN to origin consistently stayed above 300.

Two Deployed Mitigations. Four Were Still Discussing Them.

Baidu acknowledged the report, rated the connection attack medium severity and the bandwidth attack high, paid a bounty of roughly $350, and deployed the researchers’ mitigations. Tencent acknowledged it, rated the connection attack medium severity, paid roughly $150, and deployed mitigations limiting CDN-to-origin connections and capping header size in the dynamic table.

Alibaba, Cloudflare, CloudFront and Fastly acknowledged the report and were still discussing the reported vulnerabilities internally when the paper was finalized. No mitigations are recorded for them.

Exposure can be read two ways, and the readings disagree. By mechanism, Baidu, Tencent and Alibaba have the widest attack surface, supporting the dynamic table and open to the connection attack. Cloudflare has the narrowest, with no dynamic table and as the only one the connection attack failed against, because it already buffers the complete request before opening an origin connection. By measured reach the order nearly inverts: of the 42,330 subdomains flagged, CloudFront accounts for 17,431 and Cloudflare for 12,371, with Fastly on 11,606, against 720 for Alibaba, 184 for Tencent and 18 for Baidu. The three without dynamic-table support account for 41,408 of the 42,330, close to 98 percent.

Among the three CDNs supporting the dynamic table, Baidu and Tencent had deployed mitigations by then. Alibaba had not. The paper does not say why, and we have not asked Alibaba for an explanation.

It is worth being careful with what this means. The paper is a snapshot taken before publication. It does not give the disclosure date for each vendor or how long each had to respond, and the four may have moved since. We have not asked them for an explanation of their status at the paper’s cutoff. What can be said is that two had deployed mitigations by the time the paper was finalized and four had not.

What a Site Owner Can and Cannot Do

Most security stories end with a version number. This one does not, and that is what makes it awkward for hosting providers and their customers.

Every mitigation the researchers propose is applied at the CDN, and they divide by attack. Header size caps, per-stream reference limits and a ceiling on decompressed request size address the bandwidth attack. Buffering complete requests before opening an origin connection, limiting how many origin connections one client connection can trigger, and timing those connections out independently address the connection attack. None is something a site owner can configure. The one lever on the customer side is blunt: HTTP/3 has to be enabled for either attack to work, so switching it off, where a provider exposes that setting, removes the precondition at the cost of the performance HTTP/3 was adopted for. That is a workaround, not a repair.

The practical question for anyone running sites behind a CDN is therefore not what to update but what to ask. Whether the provider supports the QPACK dynamic table determines whether the higher-amplification variant of the bandwidth attack applies at all, while the mitigations it has deployed determine what exposure remains to either attack. Both are questions the provider should be able to answer directly.

There is no CVE and no reported exploitation in the wild, so there is no evidence of an active campaign. The authors describe the practical impact as severe and widespread, and argue that an attacker needs only an ordinary laptop. It is a question worth putting in writing to a supplier while the research is fresh and the answer is a matter of record rather than of damage control.

About the Data

All figures, vendor responses and mitigations come from the researchers’ paper, read directly rather than from coverage of it. The amplification rates are the maxima the authors measured under their own test conditions, not observed attack traffic. The paper was posted on 29 July and picked up by the security press on 20 August; the disclosure status reflects the paper as written, and we have not independently asked the six providers where they stand today.