Die beiden Angriffswege heißen HTTP/3 Bandwidth Amplification (HBA) und HTTP/3 Connection Amplification (HCA). Beide beruhen laut dem Forschungsteam auf demselben Einsatzmuster: Das CDN unterstützt kein durchgängiges HTTP/3, sondern terminiert HTTP/3 am Rand und übersetzt anschließend auf HTTP/1.1 in Richtung Ursprungsserver.
HBA nutzt QPACK aus, das mit HTTP/3 eingeführte Verfahren zur Header-Kompression. Da HTTP/1.1 kein entsprechendes Gegenstück kennt, muss das CDN kleine Indexwerte wieder in vollständige rohe Header zurückverwandeln, bevor es die Anfrage weiterleitet. So verursacht eine Anfrage, die den Angreifer auf der Leitung nur wenige Byte kostet, am Ursprungssystem die volle dekomprimierte Größe. Der Faktor von bis zu 350 gilt laut Studie nur für Alibaba, Baidu und Tencent. Diese drei Anbieter unterstützen die dynamische QPACK-Tabelle; der Spitzenwert wurde bei rund 64 gleichzeitigen Streams gemessen. Bei Cloudflare, CloudFront und Fastly lag das Maximum zwischen 36,41 und 51,2.
Für die Variante mit dynamischer Tabelle muss der Angreifer zunächst eine HTTP/3-Anfrage mit großem Header senden, die das CDN in die Tabelle einträgt, und diesen Eintrag anschließend wiederholt über kleine Indexwerte referenzieren. Unterstützt wird das nur von Alibaba, Baidu und Tencent; alle drei werben laut Studie mit einer 4-KB-Tabelle und einer maximalen Eintragsgröße von 3.072 Byte. Auf Angreiferseite blieb die Bandbreite bei den drei CDNs mit dynamischer Tabelle unter 500 KBit/s, bei den übrigen unter 5 MBit/s. Am Ursprungsserver wurden durchgehend mehr als 100 MBit/s gemessen.
HCA zielt nicht auf Bandbreite, sondern auf die Verbindungskapazität. Fünf der sechs CDNs öffnen nach Darstellung der Forscher bereits dann eine HTTP/1.1-Verbindung zum Ursprungsserver, wenn sie den HTTP/3-HEADERS-Frame empfangen haben, also noch bevor der Request-Body eintrifft. Weil HTTP/3 Multiplexing erlaubt, kann eine einzige Client-Verbindung mehrere Streams tragen, von denen jeder eine eigene Backend-TCP-Verbindung auslöst. Werden DATA-Frames dann nur sehr langsam gesendet, bleiben diese Verbindungen offen, während das CDN die Anfrage weiter als unvollständig behandelt.
Im Test mit einem Apache-Server, der auf 300 Sekunden Timeout und 256 Verbindungen begrenzt war, zwangen vier HTTP/3-Verbindungen mit jeweils 96 Streams den Server zu 384 Backend-Verbindungen. Bei Fastly waren dafür 48 Verbindungen mit je 8 Streams nötig, weil der Anbieter Backend-Verbindungen auf 10 pro HTTP/3-Verbindung begrenzt. Die Antwortzeiten eines unbeteiligten Clients stiegen bei Alibaba auf 60 Sekunden und bei Baidu sowie CloudFront auf bis zu 90 Sekunden; beide lieferten dabei HTTP 504 Gateway Timeout zurück. Bei Fastly stieg die Zeit auf 15 Sekunden bei HTTP 503 Service Unavailable. Tencent schloss die Client-seitige Verbindung rund 10 Sekunden nach einer Testanfrage und lieferte keine Antwort.
Für die Reichweitenabschätzung werteten die Forscher Subdomains aus der Tranco-Top-1M-Liste aus, untersuchten deren CNAME- und NS-Einträge, glichen sie mit bekannten CDN-Suffixen ab und testeten sie mit aioquic. Ergebnis waren 151.685 Subdomains bei den sechs Anbietern; 42.330 antworteten auf eine HTTP/3-Anfrage und wurden als potenziell verwundbar eingestuft. Die höchsten Zahlen entfielen auf CloudFront mit 17.431, Cloudflare mit 12.371 und Fastly mit 11.606. Der Test belegt laut Studie allerdings nur, dass der CDN-Rand auf HTTP/3 reagiert; kein fremder Ursprungsserver außerhalb des eigenen Testaufbaus wurde angegriffen.
Tencent hat nach Angaben im Offenlegungsteil die Zahl der Verbindungen vom CDN zum Ursprungsserver begrenzt und die Größe von Headern in der dynamischen Tabelle eingeschränkt. Der gleiche Abschnitt nennt Bug-Bounty-Prämien von rund 350 US-Dollar von Baidu und 150 US-Dollar von Tencent. Die vier anderen Anbieter hätten die Meldung bestätigt und intern noch beraten. Ob die Angriffe nach den Gegenmaßnahmen von Baidu und Tencent erneut getestet wurden, sagt die Arbeit nicht. Auch eine Veröffentlichung des Angriffscodes oder des Messrahmens wird darin nicht angekündigt.
Die Arbeit stammt von Forschern der National University of Singapore, der Fuzhou University, der University of Sheffield und der Johns Hopkins University und soll auf dem Symposium on Reliable Distributed Systems in Rom vorgestellt werden. Im Umfeld von QPACK und QUIC gab es zuletzt weitere Meldungen: Am 8. Juli berichtete FoxIO-Forscher Sébastien Féry, dass rund 260 Byte spezifikationskonformer QPACK-Datenverkehr jeden Server mit XQUIC abstürzen lassen könnten, Alibabas QUIC- und HTTP/3-Bibliothek für den Tengine-Webserver. Zudem veröffentlichte das OpenSSL Project am 13. August CVE-2026-14456, eine Schwachstelle mit niedriger Einstufung, bei der ein QUIC-Server eingehende Kanäle für unbekannte Ziel-Verbindungskennungen ohne Begrenzung in eine Warteschlange aufnimmt; die Korrektur führt standardmäßig ein Limit von 256 wartenden Verbindungen ein.