Content Delivery Networks (CDNs) machen Inhalte schnell verfügbar, indem sie Anfragen an ihren Edge-Standorten übernehmen. Genau hier setzt die aktuelle Sicherheitsforschung an: Unter dem Titel CDN Tsunami wurden zwei Denial-of-Service-(DoS)-Angriffe vorgestellt, die die Umwandlung von HTTP/3-Verkehr in HTTP/1.1-Requests ausnutzen. Dadurch kann aus einer vergleichsweise „kleinen“ Anfrage-Last am Client eine deutlich höhere Belastung für den Origin-Server werden.
Die Untersuchungen zeigen außerdem, dass nicht alle Anbieter gleich betroffen sind. In Tests wurden unterschiedliche Verstärkungsfaktoren gemessen, und bei einer Variante blieb ein Anbieter sogar komplett unbeschadet. Konkrete CVE-IDs wurden nicht vergeben, zudem gibt es laut Bericht keine Meldungen über Ausnutzung in freier Wildbahn.
Wie CDN Tsunami funktioniert: HTTP/3 am Edge, HTTP/1.1 zum Origin
Der Kernpunkt liegt in einer Lücke, die Forschende als Deployment Gap beschreiben: Ein CDN spricht mit dem Browser HTTP/3, aber gegenüber der dahinterliegenden Website wird nur HTTP/1.1 verwendet. Dieses Übersetzungs- oder Konvertierungsverhalten führt dazu, dass der Origin Server mehr Arbeit leisten muss, als der Angreifer auf der Client-Seite scheinbar „bezahlt“.
Die Autoren stellen dabei klar, dass CDNs nicht als End-to-End-Lösung für HTTP/3 ausgelegt seien. Für die Angriffslogik ist genau dieses „Mismatch“ entscheidend: Was am Edge kompakt oder effizient kodiert sein kann, muss beim Übergang zu HTTP/1.1 aufgelöst und in einen für den Origin passenden Request überführt werden.
HTTP/3 Bandwidth Amplification (HBA): QPACK als Verstärker
Die erste Technik nennt sich HTTP/3 Bandwidth Amplification (HBA). Sie nutzt QPACK, also das Header-Kompressionsverfahren, das mit HTTP/3 eingeführt wurde. Der entscheidende Unterschied: HTTP/1.1 besitzt kein direkt vergleichbares Mechanismus für diese Art von komprimierten Header-Referenzen.
Dadurch muss das CDN jede kleine Indexangabe, die es vom Client erhält, beim Weiterleiten an den Origin in einen vollständigen, „entpackten“ Header umwandeln. Vereinfacht: Ein Angreifer kann am Client mit wenigen Bytes arbeiten, während der Origin die entpackte Größe spürbar abbekommt.
Welche CDNs besonders stark betroffen waren
Der Verstärkungsfaktor wurde in den Tests bis in den Bereich von rund 350x für bestimmte Anbieter beobachtet – allerdings nicht bei allen gleich. Der Faktor „350x“ wird im Bericht als maximaler Charakter bzw. Gesamtwirkung aus den untersuchten Konstellationen beschrieben; in der Aufschlüsselung werden konkrete Werte genannt.
- Baidu: 66,06x (QPACK dynamic table unterstützt)
- Alibaba: 65,8x (QPACK dynamic table unterstützt)
- Tencent: 54,08x (QPACK dynamic table unterstützt)
- Amazon CloudFront: 51,2x (kein dynamic table Support)
- Cloudflare: 48,27x (kein dynamic table Support)
- Fastly: 36,41x (kein dynamic table Support)
Wichtig: Die Autoren geben an, dass die dynamische Tabelle für die Variante mit den höchsten Verstärkungswerten eine Rolle spielt. Für die dynamische Variante ist laut Bericht ein zweistufiges Vorgehen nötig: Zuerst wird eine HTTP/3-Anfrage mit großem Header gesendet, damit das CDN diesen Inhalt in der dynamischen QPACK-Tabelle ablegt. Danach werden derselbe Eintrag wiederholt über kleine Indexwerte referenziert.
Bei den drei Anbietern, die den QPACK-dynamic-table Ansatz unterstützen (Alibaba, Baidu und Tencent), blieb die Angreiferbandbreite in den Tests unter 500 Kbps, während die am Origin gemessene Bandbreite durchgehend über 100 Mbps lag.
HTTP/3 Connection Amplification (HCA): viele Backend-Verbindungen
Die zweite Technik heißt HTTP/3 Connection Amplification (HCA). Hier geht es weniger um Bandbreite, sondern um Verbindungs- und Kapazitätsauslastung. Das Vorgehen zielt darauf, dass ein CDN für viele Streams jeweils eigene Backend-Verbindungen öffnet.
In der getesteten Logik öffnen fünf von sechs CDNs schon dann eine HTTP/1.1-Verbindung zum Origin, sobald sie den HTTP/3 HEADERS-Frame erhalten – noch bevor die eigentlichen DATA-Frames ankommen. Da HTTP/3 eine Multiplexing-Funktion bereitstellt, kann ein einzelner Client-Connection mehrere parallele Streams transportieren. Jeder dieser Streams triggert dann potenziell weitere TCP-Verbindungen zum Backend.
Damit diese Verbindungen „offen“ bleiben, sendet der Angreifer Daten sehr langsam (oder verzögert sie stark). Dadurch behandelt das CDN die Anfrage weiterhin als unvollständig und hält die Ressourcenbindung aufrecht.
Ergebnisse im Labor
Die Forschenden testeten gegen einen Apache-Server mit einem Timeout von 300 Sekunden und einer Obergrenze von 256 Verbindungen. Dabei konnten je nach CDN-Konfiguration unter bestimmten Bedingungen sehr viele Backend-Verbindungen entstehen: Im Bericht werden Zahlen wie 384 erzwungene Backend-Verbindungen genannt, während ein Anbieter eine andere Limitierungskurve zeigt (Fastly benötigte in den Tests 48 Verbindungen mit je 8 Streams, weil Backend-Verbindungen pro HTTP/3-Connection gedeckelt sind).
Die Reaktionen für „benigne“ Clients reichten von HTTP-504 Gateway Timeout (u. a. Alibaba, Baidu, CloudFront) bis zu HTTP-503 Service Unavailable (Fastly). Tencent hingegen schloss die Client-Verbindung nach kurzer Zeit und gab dabei keine Antwort auf eine Probe.
Zusätzlich berichten die Forschenden, dass die Angriffe in ihren Experimenten durch selbst gesetzte Grenzen limitiert waren (Origin auf 100 Mbps, Angreifer auf 30 Mbps). Eine Aussage, ob die Effekte bei größeren Kapazitäten noch stärker ausfallen, wird zwar als plausibel beschrieben, jedoch nicht mit eigenen Tests belegt.
Erhöhte Reichweite: Wie viele Subdomains potenziell betroffen waren
Um die praktische Exponierung abzuschätzen, identifizierten die Forschenden Subdomains auf Basis der Tranco-Top-1M-Liste. Anschließend wurden CNAME- und NS-Records ausgelesen, mit bekannten CDN-Suffixen abgeglichen und jede Subdomain mit einem HTTP/3-Probe abgerufen.
Das führte zu einer großen Zahl an potenziellen Kandidaten: Insgesamt wurden 151.685 Subdomains gefunden, die bei den sechs untersuchten Anbietern gehostet sein könnten. Davon reagierten 42.330 auf HTTP/3-Anfragen und wurden daher als potenziell verwundbar markiert. Die meisten solchen Treffer stammten von Amazon CloudFront (17.431), Cloudflare (12.371) und Fastly (11.606).
Die Autoren betonen dabei, dass der Probe-Aufruf vor allem zeigt, dass der CDN-Edge HTTP/3 bedient – und dass in diesem Rahmen keine Origin-Server außerhalb des eigenen Testaufbaus angegriffen wurden.
Warum es keine CVEs und keine Wildnutzung gibt
Im Bericht werden keine CVE-Identifikatoren genannt, und es gibt keine Hinweise auf Ausnutzung in freier Wildbahn. Das bedeutet: Zwar sind die Konzepte und Testergebnisse wissenschaftlich beschrieben, jedoch ist nach dem Stand des Artikels nicht dokumentiert, dass Angreifer diese konkreten Muster bereits breit einsetzen.
Außerdem erwähnen die Forschenden, dass die beiderlei Mitigations nicht auf der Seite des Origin-Servers vorgenommen wurden, sondern bei den CDNs selbst.
Welche Gegenmaßnahmen wurden umgesetzt
Die Forscher haben konkrete Vorschläge an die betroffenen Anbieter adressiert. Diese Mitigations lassen sich in zwei Stränge teilen: Maßnahmen für den QPACK-basierten Bandbreitenhebel und Maßnahmen für die Ressourcenbindung beim Öffnen von Backend-Verbindungen.
- QPACK dynamic table begrenzen: Cap der Größe einzelner Header-Feld-Einträge (z. B. 512 Byte vorgeschlagen)
- Referenzhäufigkeit begrenzen: Maximal wie oft ein dynamic-table Eintrag in einem Stream referenziert werden darf (z. B. nicht mehr als 10)
- Entpackte Request-Größe begrenzen: Maximal erlaubte decompressed HTTP/1.1 Request Size; darüber verwerfen (z. B. 64 KB)
- Buffering vor Backend-Connection: Vollständige HTTP/3 Requests (HEADERS und DATA) puffern, bevor eine Verbindung zum Origin geöffnet wird
- Verbindungsanzahl limitieren: Begrenzen, wie viele CDN→Origin Verbindungen eine einzelne HTTP/3 Client-Connection auslösen kann
- Origin-Verbindungen unabhängig timen: Timeout für CDN→Origin Connections ohne aussagekräftig weitergeleitete Daten (z. B. 30 Sekunden vorgeschlagen)
Laut Bericht haben Baidu und Tencent die vorgeschlagenen Fixes umgesetzt. Die anderen vier Anbieter hätten die Offenlegung anerkannt, aber die Forschenden geben an, dass die Ergebnisse intern noch diskutiert würden. Ob nach dem Patch-Neuabschluss erneut mit denselben Methoden nachgetestet wurde, wird nicht berichtet.
Ausblick: Weitere QPACK- und QUIC-ähnliche Risiken
Der Bericht ordnet die Entwicklung zusätzlich in eine Reihe von verwandten Themen ein: QPACK stand bereits früher im Fokus, als ein separater Fehler am 8. Juli gemeldet wurde. Dabei ging es um spek-konforme QPACK-Traffic, der Server mit XQUIC zum Absturz bringen könne – inklusive konkreter Nennung einer QUIC/HTTP-3-Bibliothek, die auch bei Alibaba-Umgebungen zum Einsatz kommt.
Darüber hinaus wurde im Umfeld von QUIC-Servern auch eine Schwachstelle im OpenSSL-Projekt offengelegt, die mit dem Queuing unbekannter Destination Connection IDs zusammenhängt. Für den Kontext ist wichtig: Mehrere Komponenten rund um QUIC, HTTP/3 und QPACK zeigen, wie sensibel die jeweiligen Implementierungen auf Grenzfälle reagieren können.
Fazit: CDN Tsunami als Weckruf für Edge-to-Origin Übersetzungen
CDN Tsunami macht deutlich, dass die Geschwindigkeit und Bequemlichkeit von CDNs sicherheitstechnisch auch eine Kehrseite haben kann: Wenn HTTP/3 am Client akzeptiert wird, aber HTTP/1.1 zum Origin gesendet wird, entstehen Übersetzungslücken, die sich für DoS-Verstärkung nutzen lassen.
In den vorgestellten Laborversuchen führten zwei unterschiedliche Angriffsmuster – einmal über Header-Kompression und einmal über Verbindungsaufbau – zu erheblichen Belastungen für den Origin. Gleichzeitig zeigt der Bericht, dass gezielte Gegenmaßnahmen direkt auf CDN-Ebene möglich sind und von einzelnen Anbietern bereits umgesetzt wurden.
Für Website-Betreiber bleibt die praktische Konsequenz vor allem organisatorisch: Prüfen, wie das verwendete CDN HTTP/3 bereitstellt und welche Schutzmechanismen gegen Amplification- und Connection-Last existieren. Für die technische Community ist der Befund ein klarer Hinweis darauf, dass „End-to-End“-Konsistenz und saubere Behandlung von Übersetzungslogik zentrale Bausteine moderner Web-Sicherheitsarchitektur sind.
Quelle: https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html
