Onderzoekers hebben twee nieuwe denial-of-service-aanvallen beschreven die draaien om één specifiek detail: veel content delivery networks (CDN’s) nemen HTTP/3-keerwensen van de browser over, maar vertalen die naar HTTP/1.1 richting de website achter de CDN. Die vertaalslag kan een klein verzoek uit de browser uitvergroten tot een veel zwaardere impact op de origin-server. In het slechtste geval spreken de onderzoekers over een HTTP/3 vertaalslag DoS met een amplificatiefactor tot 350x.
De aanvallen kregen samen de naam “CDN Tsunami” en werden getest tegen meerdere grote CDN-aanbieders. Er zijn geen CVE’s gepubliceerd en er is (volgens de onderzoekers) geen bewijs van misbruik in het wild. Toch is het verhaal relevant voor elke organisatie die via CDN’s HTTP/3 aan gebruikers aanbiedt.
Wat is “CDN Tsunami” precies?
De kern van het probleem is een mismatch in wat de CDN met de bezoeker afspreekt en wat de CDN vervolgens met de backend doet. Aan de clientkant kan de CDN HTTP/3 gebruiken (aan de edge). Aan de kant van de website achter de CDN gaat de communicatie echter over HTTP/1.1. Dat betekent dat de CDN requests uit HTTP/3 moet omzetten naar een vorm die HTTP/1.1 kan doorgeven.
Die omzetting kost rekenkracht én kan leiden tot een grotere hoeveelheid data richting de origin, zelfs wanneer de attacker aan de voorkant weinig verkeer verstuurt. Door die discrepantie kunnen aanvallers de serverbelasting op de verkeerde plek laten “opbouwen”.
Door welke CDN’s is het onderzocht?
De onderzoekers evalueerden de aanvalstechnieken tegen zes providers: Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly en Tencent. In alle gevallen bleek de CDN in kwestie gevoelig voor een bandwidth-variant. Daarnaast bleek een meerderheid gevoelig voor een connection-variant.
Opvallend detail: bij Cloudflare werd de connection-gerelateerde aanval minder bruikbaar gevonden, omdat de CDN het verzoek volledig bufferde voordat het een verbinding naar de origin opende. Daarmee verdwijnt een deel van het “incomplete request”-effect dat de aanvallen nodig hebben.
Twee varianten: bandwidth amplificatie en connection amplificatie
De onderzoekers onderscheiden twee technieken, allebei gestoeld op dezelfde structurele vertaalkloof (HTTP/3 aan de edge, HTTP/1.1 naar de origin):
- HTTP/3 Bandwidth Amplification (HBA)
- HTTP/3 Connection Amplification (HCA)
Beide varianten vergroten de impact op de backend, maar ze doen dat op een andere manier: de ene door meer data te forceren richting origin, de andere door de origin-verbindingen te laten exploderen.
HTTP/3 Bandwidth Amplification (HBA)
HBA grijpt in op QPACK, een headercompressiemechanisme dat bij HTTP/3 hoort. Het idee is dat een attacker herhaaldelijk compacte header-informatie kan refereren. Maar omdat HTTP/1.1 geen equivalent mechanisme heeft, moet de CDN de compacte waarden weer uitklappen naar volledige, on-gecomprimeerde headers voordat het kan doorsturen.
Daardoor kan een verzoek dat aan de clientzijde maar enkele bytes kost, aan de originzijde ineens veel groter uitpakken. In de tests bleef de aanvallers-bandbreedte laag (onder 500 Kbps bij de providers die QPACK dynamic table ondersteunen, en onder 5 Mbps bij de rest), terwijl de gemeten bandbreedte naar de origin opliep tot ruim 100 Mbps.
De onderzoekers rapporteren amplificatiefactoren die (afhankelijk van de provider en de gebruikte tabel) in het hoogste scenario richting de orde van 60x tot ruim 50x gaan, met de topwaarden voor providers die dynamic table ondersteunen.
Wat maakte HBA extra “effectief”?
De dynamic-table variant vraagt om een voorbereidende stap: de attacker stuurt eerst een HTTP/3-request met een grote header, zodat de CDN die header in een QPACK dynamic table plaatst. Daarna kan de attacker die entry vervolgens meerdere keren opnieuw gebruiken met kleine indexwaarden.
De ondersteuning van deze dynamic table bleek beperkt tot Alibaba, Baidu en Tencent. In de publicatie wordt gesproken over een tabelgrootte van 4KB en een maximum entry-grootte van 3.072 bytes.
HTTP/3 Connection Amplification (HCA)
Bij HCA draait het minder om “hoeveel bytes” er binnenkomen, en meer om “hoeveel verbindingen” er ontstaan tussen CDN en origin. Waar de client HTTP/3 multiplexing kan gebruiken (meerdere streams op één verbinding), open de CDN vaak vroegtijdig een eigen HTTP/1.1 verbinding naar de origin wanneer het de HEADERS-fragmenten ontvangt.
Vervolgens kan een attacker de DATA-fragmenten heel langzaam of met vertraging sturen, waardoor die origin-verbindingen open blijven terwijl de CDN het verzoek nog als incompleet behandelt. Dat kan leiden tot een snelle uitputting van origin-connection resources.
In een test tegen een Apache-configuratie met een timeout van 300 seconden en een limiet van 256 verbindingen zagen de onderzoekers dat slechts een beperkt aantal HTTP/3 clientverbindingen kon leiden tot honderden backend-verbindingen.
Effect op responstijden en foutcodes
De resultaten liepen uiteen per provider. Bij Alibaba liepen responstijden richting 60 seconden. Bij Baidu en CloudFront werden HTTP 504 Gateway Timeout-antwoorden gerapporteerd, terwijl Fastly opliep tot HTTP 503 Service Unavailable en responstijden lager maar nog steeds problematisch waren.
Tencent sloot in de tests de clientzijde ongeveer 10 seconden na ontvangst van een probe en leverde geen response op. Dat maakt HCA daar minder “meetbaar” in dezelfde vorm.
Waarom dit volgens de onderzoekers zonder CVE blijft
Er zijn volgens de publicatie geen CVE-identificaties toegewezen. Ook meldt men geen bekende exploitatie in het wild. Dat betekent niet dat het risico verdwijnt, maar wel dat de exacte, individuele kwetsbaarheid mogelijk niet als één CVE is te vatten: het gaat om een deployment- en vertaallogica-gap die bij meerdere CDN’s terug kan komen.
Mitigaties: wat moet een CDN doen?
De onderzoekers geven aan dat de voorgestelde oplossingen vooral op CDN-niveau worden doorgevoerd, dus niet op de website achter de CDN. Ze richten zich op het beperken van de schade bij het uitklappen van headers en op het verminderen van het aantal (of de duur) van backend-verbindingen.
Voor HBA (bandwidth) worden onder meer de volgende maatregelen genoemd:
- Beperk de grootte van een headerveld-entry in de QPACK dynamic table (suggestie: 512 bytes)
- Beperk hoe vaak één dynamic table entry in dezelfde stream kan worden gerefereerd (suggestie: maximaal 10)
- Hanteer een maximum op de grootte van de decompressed HTTP/1.1 request en weiger te grote requests (suggestie: 64KB)
Voor HCA (connections) stellen de onderzoekers mitigaties voor zoals:
- Buffer volledige HTTP/3 requests (zowel HEADERS als DATA) voordat een CDN-to-origin verbinding wordt geopend
- Beperk hoeveel origin-verbindingen een enkele HTTP/3 clientverbinding kan triggeren
- Time-out CDN-to-origin verbindingen onafhankelijk van de client (suggestie: 30 seconden zonder betekenisvolle forwarded data)
De publicatie meldt dat Baidu en Tencent bevestigden wat ze zagen en fixes implementeerden. De overige providers zouden de bevindingen hebben erkend en intern nog bespreken.
Hoe groot is de mogelijke blootstelling?
Om te schatten waar het mis kan gaan, onderzochten de onderzoekers subdomeinen op basis van de Tranco Top 1M lijst. Ze inventariseerden CNAME- en NS-records, matchten die met bekende CDN-suffixen en deden probes via aioquic.
Dat leverde 151.685 subdomeinen op die bij de zes onderzochte providers hoorden. Daarvan reageerden 42.330 op een HTTP/3-request en werden ze gemarkeerd als “mogelijk kwetsbaar”. De hoogste aantallen kwamen van CloudFront, Cloudflare en Fastly.
Belangrijk: volgens de onderzoekers bevestigt die probe vooral dat de CDN HTTP/3 spreekt aan de edge, en dat de origin in het testscenario niet buiten hun eigen setup werd aangevallen.
Is dit al eerder gezien bij HTTP/2?
De onderzoekers vergelijken hun bevindingen met een eerdere studie (CDN Judo, uit 2020) over een vergelijkbare vertaalsituatie bij HTTP/2→HTTP/1.1. Daar werden amplificatiefactoren gerapporteerd die (afhankelijk van de gebruikte tabelvariant) in sommige scenario’s in dezelfde orde van grootte lagen.
Wat nieuw is in deze campagne, is de focus op de HTTP/3-side, inclusief QPACK-dynamiek en multiplexing-effecten rondom connection opbouw naar de origin.
Wat kun je als organisatie nu doen?
Als klant heb je niet altijd directe controle over hoe een CDN intern HTTP/3 vertaalt. Toch kun je wél gerichte stappen zetten om je risico te beperken en sneller te detecteren.
- Check of je CDN HTTP/3 vertaalt naar HTTP/1.1 en of er recent mitigaties zijn uitgerold.
- Let op DDoS-patronen waarbij “small-ish” verkeer ongewoon hoge origin-belasting veroorzaakt (bijv. spikes in time-outs of 50x-fouten).
- Afstemming tussen edge en origin: zorg dat time-outs, limieten en logging zodanig zijn ingesteld dat je snel ziet of verbindingen “hangen” of resources worden leeggetrokken.
- Werk met vendor-advies: omdat de maatregelen vooral CDN-side zijn, loont het om de aanbevelingen van je provider te volgen en te documenteren wat er is aangepast.
Heb je te maken met bredere DoS- en beveiligingsvraagstukken rondom edge en netwerkvertaling? Dan kan ook het bredere thema van aanvalsmethodes en mitigaties je helpen om beter te prioriteren, zoals in artikelen over DDoS-achtige technieken en patch/mitigation trajecten.
Daarnaast is het relevant om security-problemen in CDN- en edge-context niet los te zien van andere “vertalingslagen” in je stack. Zo behandelen we bijvoorbeeld ook kwesties rond hoe infrastructuur en componenten elkaar beïnvloeden bij het beveiligen van systemen en het voorkomen van ongewenste impact—bekijk bijvoorbeeld onze kijk op AI modelbeveiliging met sandboxing als denkrichting voor het scheiden van kwetsbare zones en het beperken van cascading effecten.
Conclusie: CDN’s blijven een vertaalkloof blootstellen
“CDN Tsunami” laat zien hoe een ogenschijnlijk onschuldig detail—HTTP/3 aan de clientzijde maar HTTP/1.1 naar de origin—kan leiden tot HTTP/3 vertaalslag DoS. Met een beperkte hoeveelheid clientverkeer kan de origin aanzienlijk zwaarder worden belast, zowel in bytes als in verbindingen. De onderzoekers rapporteren amplificatie-effecten tot honderden keren in specifieke scenario’s, en adviseren mitigaties die vooral bij CDN’s moeten landen.
Voor organisaties betekent dit vooral: monitor de impact op je origin bij edge-verkeer, vraag je CDN-provider om transparantie over HTTP/3-naar-origin vertaallogica en volg mitigatie-updates nauwgezet. Daarmee verklein je de kans dat een vertaalkloof een route wordt naar downtime.
Bron: https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html
