Cybersecurity-onderzoekers hebben twee Denial-of-Service (DoS)-aanvallen onthuld die misbruik maken van de manier waarop grote Content Delivery Networks (CDN’s) clientgericht HTTP/3-verkeer omzetten in HTTP/1.1-verzoeken aan de websites waar zij zich op richten, waardoor een verzoekstroom met lage bandbreedte tot 350x wordt versterkt ten opzichte van de oorspronkelijke server.
De aanvallen, gezamenlijk genaamd “CDN-tsunami,” werden geëvalueerd tegen Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly en Tencent.
Alle zes werden gevoelig bevonden voor de bandbreedtevariant en vijf voor de verbindingsvariant, waarbij Cloudflare niet werd beïnvloed door de laatste omdat het het volledige verzoek buffert voordat een verbinding met de oorsprong wordt geopend.
Voor de aanval is een website nodig die wordt gehost op een van de zes providers, met HTTP/3 aan de rand, en er zijn geen configuratiewijzigingen aan de kant van de website. In het artikel wordt vermeld dat HTTP/3 standaard is ingeschakeld bij Cloudflare en CloudFront.
De documentatie van Cloudflare beschrijft echter dat HTTP/3 beschikbaar is op alle abonnementen en biedt stappen om dit in te schakelen, in plaats van te vermelden dat het standaard is ingeschakeld. AWS-documentatie geeft http2 als de standaard HTTP-versie voor nieuwe CloudFront-distributies.
De factor 350x is alleen van toepassing op Alibaba, Baidu en Tencent. Deze drie providers ondersteunen de dynamische tabel QPACK en deze werd gemeten bij ongeveer 64 gelijktijdige streams, waarbij het maximum op Cloudflare, CloudFront en Fastly varieerde van 36,41x tot 51,2x.
Er zijn geen CVE-identificatoren toegewezen en er is geen melding gemaakt van exploitatie in het wild. Terwijl Baidu en Tencent de rapporten bevestigden en de voorgestelde oplossingen implementeerden, zeggen de onderzoekers dat elke voorgestelde beperking wordt toegepast op het CDN in plaats van op de oorspronkelijke website.
De twee technieken worden genoemd HTTP/3 bandbreedteversterking (HBA) En HTTP/3-verbindingsversterking (HCA)en beide berusten op dezelfde implementatiekloof, waarbij een CDN HTTP/3 met de browser spreekt, maar alleen HTTP/1.1 met de website erachter, een mismatch die volgens het team bestaat omdat “CDN’s geen end-to-end HTTP/3 ondersteunen.”
HBA maakt gebruik van QPACK, het headercompressieformaat dat is geïntroduceerd met HTTP/3. Omdat HTTP/1.1 geen gelijkwaardig mechanisme kent, moet het CDN elke kleine indexwaarde die het ontvangt, terug uitbreiden naar een volledige onbewerkte header voordat het verzoek wordt doorgestuurd. Een verzoek dat de aanvaller een paar bytes aan de draad kost, kost de oorsprong dus de gedecomprimeerde grootte.
De bandbreedte aan de aanvallerszijde bleef onder de 500 Kbps ten opzichte van de drie CDN’s die de dynamische tabel ondersteunen en onder de 5 Mbps ten opzichte van de rest, terwijl het bandbreedteverbruik gemeten bij de oorsprong overal boven de 100 Mbps lag.
De dynamische tabelvariant vereist dat de aanvaller eerst één HTTP/3-verzoek verzendt met een grote header, die de CDN in de tabel invoegt, en vervolgens herhaaldelijk naar dat item verwijst met behulp van kleine indexwaarden. Ondersteuning is beperkt tot Alibaba, Baidu en Tencent, die elk een tabel van 4 KB adverteren met een maximale invoergrootte van 3.072 bytes.
De maximale bandbreedteversterkingsfactoren gemeten met behulp van de statische QPACK-tabel zijn als volgt:
- Baidu, 66.06x, dynamische tafel ondersteund
- Alibaba, 65,8x, dynamische tafel ondersteund
- Tencent, 54.08x, dynamische tafel ondersteund
- Amazon CloudFront, 51.2x, geen dynamische tafelondersteuning
- Cloudflare, 48,27x, geen dynamische tafelondersteuning
- Snel, 36,41x, geen dynamische tafelondersteuning
HCA richt zich eerder op verbindingscapaciteit dan op bandbreedte. Vijf van de zes CDN’s openen een HTTP/1.1-verbinding met de oorsprong zodra ze het HTTP/3 HEADERS-frame ontvangen, voordat de verzoektekst arriveert, en HTTP/3-multiplexing zorgt ervoor dat een enkele clientverbinding meerdere streams kan vervoeren, die elk hun eigen backend-TCP-verbinding activeren. Door DATA-frames tegen een zeer lage snelheid te verzenden, blijven die verbindingen open, terwijl het CDN het verzoek als onvolledig blijft behandelen.
Tegen een Apache-server geconfigureerd met een time-out van 300 seconden en een limiet van 256 verbindingen, forceerden vier HTTP/3-verbindingen, die elk 96 streams multiplexen, 384 backend-verbindingen, terwijl Fastly 48 verbindingen van 8 streams nodig had omdat het de backend-verbindingen beperkt tot 10 per HTTP/3-verbinding.
De responstijden voor een goedaardige klant bereikten 60 seconden op Alibaba en tot 90 seconden op Baidu en CloudFront, waarbij beide HTTP 504 Gateway Timeout retourneerden, terwijl Fastly steeg naar 15 seconden en HTTP 503 Service Unavailable retourneerde.
Tencent sloot de verbinding aan de clientzijde ongeveer 10 seconden na ontvangst van een sondeverzoek en retourneerde geen antwoord.
De experimenten werden begrensd door limieten die de onderzoekers zichzelf oplegden, waarbij de oorsprong beperkt was tot 100 Mbps en de aanvaller tot 30 Mbps. Er is geen enkele test gerapporteerd die hoger is dan deze cijfers. Het artikel stelt dat de aanvallen zich uitbreiden naar servers met een hogere capaciteit, een bewering die niet wordt getest.
De versterkingsfactor bleek ook een piek te bereiken bij 64 gelijktijdige streams en vervolgens af te nemen, wat de onderzoekers toeschrijven aan CPU-overhead aan de CDN-rand. Er worden echter geen edge-CPU-metingen gepresenteerd.
Om de blootstelling te meten, heeft het team subdomeinen opgesomd onder de Tranco Top 1M-lijst, hun CNAME- en NS-records gecrawld, deze vergeleken met bekende CDN-toegewezen achtervoegsels en elk daarvan onderzocht met behulp van aioquic.
Dat leverde 151.685 subdomeinen op die werden gehost door de zes providers, waarvan er 42.330 reageerden op een HTTP/3-verzoek en als potentieel kwetsbaar werden bestempeld, met de grootste aantallen van CloudFront (17.431), Cloudflare (12.371) en Fastly (11.606). Uit het onderzoek blijkt alleen dat de CDN-edge reageert op HTTP/3 en dat geen enkele origin-server buiten de eigen testopstelling van de onderzoekers is aangevallen.
De resultaten worden in het artikel vergeleken met CDN Judo, een onderzoek uit 2020 naar de equivalente HTTP/2-naar-HTTP/1.1-conversie bij CDN’s, die factoren rapporteerden van ongeveer 44x met de statische tabel en 166x met de dynamische tabel.
De beperkende maatregelen die aan de leveranciers worden opgelegd, worden toegepast bij het CDN en zijn als volgt:
- Beperk de grootte van elk enkel koptekstveldinvoer dat in de dynamische tabel van QPACK wordt ingevoegd, voorgesteld op 512 bytes
- Beperk het aantal keren dat naar één dynamisch tabelitem kan worden verwezen binnen één stream, voorgesteld op niet meer dan 10
- Dwing een maximale gedecomprimeerde HTTP/1.1-verzoekgrootte af en wijs alles daarboven af voordat het wordt doorgestuurd, voorgesteld op 64 KB
- Buffer het volledige HTTP/3-verzoek, zowel HEADERS als DATA-frames, voordat u een CDN-naar-oorsprong-verbinding opent
- Beperk het aantal CDN-naar-origin-verbindingen dat een enkele HTTP/3-clientverbinding kan activeren
- Time-out voor CDN-naar-oorsprong-verbindingen, onafhankelijk van de clientverbinding, voorgesteld op 30 seconden zonder zinvolle doorgestuurde gegevens
De door Tencent geïmplementeerde maatregelen beperken het aantal CDN-naar-origin-verbindingen en beperken de grootte van headers in de dynamische tabel, volgens het openbaarmakingsgedeelte van het artikel, waarin ook bugbounty-beloningen van ongeveer $ 350 van Baidu en $ 150 van Tencent worden vermeld.
In hetzelfde gedeelte staat dat de andere vier leveranciers de openbaarmaking erkenden en de bevindingen nog steeds intern bespraken. De krant rapporteert niet of de aanvallen opnieuw zijn getest nadat Baidu en Tencent hun maatregelen hebben geïmplementeerd, en zegt niet of de aanvalscode of het meetraamwerk zal worden gepubliceerd.
Het werk wordt toegeschreven aan onderzoekers van de National University of Singapore, Fuzhou University, de University of Sheffield en de Johns Hopkins University. Het zal worden gepresenteerd op het Symposium on Reliable Distributed Systems in Rome van 22 tot 24 september 2026.
De dynamische tabel van QPACK was het onderwerp van een afzonderlijke fout die op 8 juli werd onthuld, toen FoxIO-onderzoeker Sébastien Féry meldde dat ongeveer 260 bytes aan spec-conform QPACK-verkeer elke server met XQUIC, Alibaba’s QUIC en HTTP/3-bibliotheek, die HTTP/3-ondersteuning biedt voor de Tengine-webserver die Alibaba via zijn cloud- en CDN-infrastructuur draait, zou kunnen laten crashen.
De ontwikkeling komt op het moment dat het OpenSSL Project op 13 augustus CVE-2026-14456 openbaarde, een zwakte van geringe ernst waarbij een QUIC-server inkomende kanalen in de wachtrij zet voor onbekende bestemmingsverbindings-ID’s zonder enige limiet af te dwingen, met een oplossing die “een limiet introduceert voor in behandeling zijnde verbindingen”, standaard ingesteld op 256.
Cloudflare zei in zijn DDoS Threat Report voor de eerste helft van 2026, dat dezelfde week werd gepubliceerd, dat het zwaartepunt van de aanval “verschoven is van botnet-overstromingen naar reflectie en versterking”, waarbij DNS-gebaseerde aanvallen verantwoordelijk waren voor 34,3% van alle activiteit op de netwerklaag in de eerste helft van 2026.
