Mit einer einzigen heimischen Internetleitung können Webserver innerhalb von Sekunden in die Knie gezwungen werden. Die HTTP/2 Bomb – eine neuartige DoS-Attacke, die am 2. Juni veröffentlicht wurde – zielt auf die Standardkonfigurationen der gängigsten Webserver-Software ab: nginx, Apache HTTPD, Microsoft IIS, Envoy und Cloudflare Pingora. Entdeckt wurde die Verwundbarkeit von Sicherheitsforschern des Unternehmens Calif, die OpenAIs Codex nutzten, um zwei seit rund zehn Jahren bekannte Angriffstechniken zu kombinieren und damit bestehende Schutzmechanismen zu umgehen.
Zwei zehn Jahre alte Verfahren, neu kombiniert
Die HTTP/2 Bomb vereint zwei bekannte Angriffsmethoden. Die erste ist die HPACK-Kompressionsexplosion. HTTP/2 verwendet HPACK, um Header zu komprimieren. Ein Angreifer kann einen ein Byte großen Index auf eine Tabelle legen, auf die der Server bei jeder Anfrage zugreift und den vollständigen Header im Speicher expandiert. Aus einem Byte auf der Leitung werden so Dutzende bis Tausende Bytes auf dem Server.
Die zweite Komponente ist eine Slowloris-ähnliche Verbindungsaufrechterhaltung. Dabei wird das Flusskontrollfenster auf null Byte gesetzt, sodass der Server keine Antwort senden kann. Kurz vor einem Timeout sendet der Angreifer ein einziges Byte großes WINDOW_UPDATEcodecodecodecodecodecode-Frame, um die Verbindung offen zu halten und den reservierten Speicher nicht freizugeben.
Beide Techniken sind seit Jahren bekannt – HPACK-Explosion als CVE-2016-6581, Slowloris-artige Zustände ebenfalls seit dieser Zeit. Doch während einzelne Maßnahmen dagegen existieren, liegt die Tücke der HTTP/2 Bomb in der Kombination, die die vorhandenen Abwehrmechanismen unterläuft.
Bisherige Gegenmaßnahmen gegen die HPACK-Explosion setzten auf eine Obergrenze für die Headergröße nach der Dekompression. Die HTTP/2 Bomb verfolgt den umgekehrten Ansatz: Der Header-Inhalt ist nahezu leer, die Amplifikation entsteht aus dem Verwaltungs-Overhead, den der Server für jeden Eintrag aufwendet. Da die dekomprimierten Daten minimal bleiben, greift die Größenbegrenzung nicht.
Gegen Server mit einer Begrenzung der Anzahl der Header – wie Apache HTTPD und Envoy – nutzt die Attacke zudem eine Besonderheit des HTTP/2-Protokolls (RFC 9113, §8.2.3): Cookie-Header dürfen explizit aufgespalten werden. Diese Teile werden nicht mitgezählt, sodass die Begrenzung umgangen werden kann.
Ein Heimanschluss, 20 Sekunden, 32 Gigabyte
Die von Calif veröffentlichten Demodaten sind eindeutig: Mit einer einzigen 100-Mbit/s-Heimleitung und einem Client konnten die Forscher gegen Apache HTTPD und Envoy in rund 20 Sekunden 32 GB Server-Arbeitsspeicher belegen und halten. Die Verstärkungsfaktoren und gemessenen Zeiten im Einzelnen:
- Envoy: Verstärkung ~5.700:1, ~10 Sekunden für 32 GB
- Apache HTTPD: Verstärkung ~4.000:1, ~18 Sekunden für 32 GB
- nginx: Verstärkung ~70:1, ~45 Sekunden für 32 GB
- Microsoft IIS: Verstärkung ~68:1, ~45 Sekunden für 64 GB
- Cloudflare Pingora: Keine öffentlichen Daten
Eine Shodan-Suche ergab, dass über 880.000 Websites eine dieser HTTP/2-fähigen Server-Software einsetzen. Zwar sind Websites hinter CDNs weniger direkt betroffen, doch viele Origin-Server terminieren HTTP/2 selbst und sind damit verwundbar.
Patch-Lage: Einige Hersteller reagieren, andere nicht
Der Umgang mit der Schwachstelle ist je nach Software unterschiedlich: nginx reagierte nach der Offenlegung im April bereits am Folgetag mit Version 1.29.8 und fügte die Direktive max_headerscodecodecodecodecodecode (Standard: 1000) hinzu. Wer nicht updaten kann, sollte HTTP/2 mit http2 off;codecodecodecodecodecode deaktivieren.
Apache HTTPD – Der Entwickler Stefan Eissing veröffentlichte am 27. Mai, dem Tag der Offenlegung, einen Patch in mod_http2 v2.0.41, dem die CVE-Nummer CVE-2026-49975 zugewiesen wurde. Der Patch ist jedoch noch nicht im offiziellen Apache-HTTPD-2.4.x-Release enthalten und muss aus dem separaten mod_http2-Repository bezogen werden. Als Workaround dient Protocols http/1.1codecodecodecodecodecode zur Deaktivierung von HTTP/2.
Envoy veröffentlichte am 3. Juni einen Patch, dessen Wirksamkeit von Calif jedoch noch verifiziert wird. Für Microsoft IIS und Cloudflare Pingora existiert zum 3. Juni noch kein Patch. Hier wird empfohlen, HTTP/2 zu deaktivieren oder vorgeschaltete Reverse-Proxys mit strengeren Header-Limits zu verwenden.
Eine wirksame generische Schutzmaßnahme, unabhängig vom Patch-Status, ist die Begrenzung des Arbeitsspeichers pro Worker-Prozess – etwa via cgroups, ulimit -vcodecodecodecodecodecode oder Container-Memory-Limits. Ein Worker, der aufgrund von OOM (Out of Memory) frühzeitig abstürzt, ist für den Gesamtserver weniger schädlich als ein vollständiges Einfrieren durch Speichermangel.
Warum die Entdeckung durch KI ein Wendepunkt ist
Die HTTP/2 Bomb offenbart mehr als nur eine neue Angriffstechnik. Beide zugrunde liegenden Verfahren waren fast ein Jahrzehnt bekannt und einzeln abgesichert. Dennoch wiesen fünf unabhängige Implementierungen die gleiche Schwachstelle auf. Calif argumentiert, dass das Problem nicht in den Implementierungen, sondern im Protokoll-Design selbst liegt, denn die Sicherheitshinweise in RFC 7541 (§7.3) adressieren das Risiko der Speichererschöpfung nur unzureichend.
Und: Es war eine KI, OpenAI Codex, die die Kombination fand, die Menschen zehn Jahre lang übersehen hatten. Thai Duong, Mitgründer von Calif und 2012 gemeinsam mit Juliano Rizzo Entdecker der CRIME-Schwachstelle, war selbst an der Entwicklung von HPACK beteiligt. Als er seine damaligen Review-Notizen erneut las, stellte er fest, dass diese Angriffskombination nie diskutiert worden war.
Calif weist zudem darauf hin, dass öffentliche Patch-Diffs ausreichen, damit KI-Modelle funktionsfähige Exploits rekonstruieren können. Nachdem die Patches für nginx und Apache HTTPD veröffentlicht wurden, leitete die KI ab, dass auch Microsoft IIS, Envoy und Pingora die gleiche Schwachstelle aufwiesen. Die Zeit von der Patch-Veröffentlichung bis zur funktionsfähigen Attacke verkürzt sich drastisch.
Administratoren von HTTP/2-Servern sollten umgehend prüfen, ob ihre Umgebung betroffen ist. Patches sind zu installieren, wo verfügbar – wo nicht, müssen HTTP/2 deaktiviert oder Speicherlimits verschärft werden. Die Technik und ein Proof of Concept sind bereits öffentlich.
