Thought Leadership
Die neu entdeckte Sicherheitslücke HTTP/2 Bomb ermöglicht Denial-of-Service-Angriffe auf verbreitete Webserver wie NGINX, Apache, IIS und Envoy.
Das IT-Sicherheitsunternehmen Calif hat eine neue Sicherheitslücke im Netzwerkprotokoll HTTP/2 öffentlich dokumentiert. Die unter dem Codenamen HTTP/2 Bomb geführte Schwachstelle ermöglicht entfernte Denial-of-Service-Angriffe (DoS) auf die weltweit am häufigsten eingesetzten Webserver. Zu den betroffenen Softwareprodukten gehören NGINX, Apache HTTPD, Microsoft IIS, Envoy sowie Cloudflare Pingora.
Nach Angaben der Analysten wurde die Schwachstelle mithilfe des KI-Modells OpenAI Codex identifiziert, indem zwei bekannte Angriffsmethoden kombiniert wurden: eine Kompressionsbombe und eine Blockade im Stil eines Slowloris-Angriffs. Calif betonte bei der Veröffentlichung die Reichweite der Bedrohung: „Das anfällige Verhalten existiert in der Standard-HTTP/2-Konfiguration jedes Servers,“. Das fundamentale Problem liegt somit in den herkömmlichen Standardeinstellungen, mit denen die Softwarepakete ausgeliefert und in Produktivumgebungen betrieben werden.
Funktionsweise der Sicherheitslücke über Metadaten-Verstärkung
Das Angriffskonzept unterscheidet sich maßgeblich von historischen Kompressionsbomben, die auf das Header-Kompressionsverfahren HPACK von HTTP/2 abzielten. HPACK komprimiert Metadaten mittels Huffman-Kodierung und reduziert die Header-Größe im Schnitt um 30 Prozent, wobei das Verfahren eigentlich resistent gegen das Auslesen von Authentisierungs-Cookies sein soll. Bisherige Angriffe wie die HPACK-Bombe aus dem Jahr 2016 (CVE-2016-6581) oder neuere Fehler in Apache (CVE-2025-53020) schleusten riesige Datenwerte in die systeminternen Tabellen ein, um den Speicher zu überlasten. Moderne Webserver sind jedoch darauf trainiert, die maximal decodierte Header-Größe zu überwachen und bei Grenzüberschreitung abzubrechen.
„Die klassische Bombe stopft einen großen Wert in die Tabelle und referenziert ihn wiederholt, sodass Server gelernt haben, die gesamte decodierte Header-Größe zu begrenzen. Unsere Variante geht den umgekehrten Weg: Der Header ist fast leer, und die Verstärkung kommt von der Buchführung pro Eintrag, die der Server darum herum zuweist. Das Limit für die decodierte Größe greift nie, weil es fast nichts zu decodieren gibt.“
Forscher von Calif
Ein einziges übertragenes Byte auf der Netzwerkleitung führt somit zu einer vollständigen, ressourcenintensiven Header-Zuweisung im Arbeitsspeicher des Servers, was pro Anfrage tausendfach wiederholt wird.
Massiver Speicherverbrauch durch dauerhaft blockierte Verbindungen
Die zweite Komponente des Angriffs nutzt eine Slowloris-Taktik auf Anwendungsebene aus. Die Angreifer setzen ein sogenanntes Zero-Byte-Flow-Control-Window ein. Dieses signalisiert dem Webserver permanent, dass der Client derzeit keine Daten empfangen kann, wodurch der Server gezwungen wird, die Verbindung offen zu halten und die zugewiesenen Speicherbereiche nicht freizugeben. In der Praxis führt dies zu einer extremen Asymmetrie zwischen dem Aufwand des Angreifers und dem Schaden auf der Opferseite.
Ein herkömmlicher Heimcomputer mit einer Standard-Internetverbindung von 100 Megabit pro Sekunde ist technisch in der Lage, einen ungeschützten Server innerhalb weniger Sekunden vollständig unerreichbar zu machen. Bei Tests gegen die Webserver Apache HTTPD und Envoy reichte ein einziger Client aus, um innerhalb von rund 20 Sekunden etwa 32 Gigabyte des serverseitigen Arbeitsspeichers komplett zu belegen und zu blockieren. Calif kritisierte in diesem Zusammenhang das zugrundeliegende HTTP/2-Protokolldesign: „Das tiefere Versäumnis besteht darin, dass die Spezifikation das Speicher-Risiko rein als Verstärkungsverhältnis darstellt, und das Verhältnis ist nur die Hälfte der Equation.“ Ein 70:1-Verstärker sei harmlos, wenn der Speicher freigegeben wird, sobald die Anfrage abgeschlossen ist. Es werde zu einem Angriff, weil HTTP/2 es dem Client ermöglicht, die Verbindung fast kostenlos offen zu halten, wodurch jedes zugewiesene Byte so lange verankert bleibt, wie er möchte.
Bereitgestellte Sicherheitsupdates und Workarounds für Administratoren
Um die Infrastrukturen gegen die Ausnutzung der HTTP/2-Bomb zu schützen, müssen Systemadministratoren umgehend administrative Gegenmaßnahmen ergreifen. Die Verfügbarkeit von Patches stellt sich je nach Softwarehersteller wie folgt dar:
- NGINX: Ein Update auf die Version 1.29.8 oder höher schließt die Sicherheitslücke durch die Einführung der neuen Direktive max_headers, die standardmäßig auf einen Maximalwert von 1000 gesetzt ist. Falls ein Update kurzfristig nicht möglich ist, sollte HTTP/2 über den Befehl http2 off; temporär deaktiviert werden.
- Apache HTTPD: Das Problem wurde in der Komponente mod_http2 in der Version v2.0.41 behoben. Als temporärer Workaround ohne Update wird empfohlen, das Protokoll über die Konfiguration Protocols http/1.1 auf den älteren Standard zu beschränken.
- Microsoft IIS, Envoy und Cloudflare Pingora: Für diese drei Plattformen steht zum aktuellen Zeitpunkt noch kein offizielles Sicherheitsupdate oder Patch zur Verfügung.
