HTTP/2-Bombe: PoCs zur Ausnutzung von Sicherheitslücken im Protokoll sind verfügbar

CVE-2026-49975

Es liegen Proof-of-Concept-Beispiele (PoC) für die Ausnutzung der unter der CVE-2026-49975 identifizierten Sicherheitslücke vor – vom Typ„Resource Exhaustion“mit einem CVSS 3.1-Wert von 7,5 und derBezeichnung „HTTP/2 Bomb“–, die die Implementierung des HTTP/2-Protokolls betrifft und Angriffe vom Typ„Denial of Service“ermöglichen könnte.

Diese CVE betrifft Implementierungen des HTTP/2-Protokolls in verschiedenen Webservern (darunter Nginx, Apache httpd, IIS, Envoy und Pingora) und resultiert aus der Kombination folgender Faktoren:

• Verstärkung durch HPACK^[1] (Compression Bomb);
• Fehlen wirksamer Begrenzungen bei internen Speicherzuweisungen;
• Missbrauch des Flusskontrollmechanismus, der die Freigabe von Speicher verhindert.

Die Sicherheitslücke resultiert aus einer ineffizienten serverseitigen Speicherverwaltung, die im HPACK-Dekomprimierungsmechanismus vorhanden ist. Im Einzelnen ermöglicht das Protokoll, einen einzelnen Header in seine dynamische Tabelle aufzunehmen und später über kompakte Darstellungen derselben darauf zu verweisen.

Das anomale Verhalten tritt beim Empfang von Frames auf, die denselben Verweis auf den Index des Headers (der in der dynamischen Tabelle gespeichert ist) enthalten, wenn dieser mehrfach wiederholt wird: Der Empfang eines kontinuierlichen Stroms kompakter Verweise veranlasst den Server, eine vollständige Kopie jedes einzelnen Verweises zu rekonstruieren und zuzuweisen, ohne dass diese Zuweisungen angemessen begrenzt oder erfasst werden (Ressourcenabrechnung).

Infolgedessen könnte die Verarbeitung einer als Eingabe bereitgestellten Nutzlast, selbst wenn diese nur von geringer Größe ist, zur Erzeugung von Tausenden doppelter Zeichenfolgen im RAM des Servers führen. Dieser Angriffsvektor lässt sich durch Manipulation der HTTP/2-Flusskontrolle noch verstärken: Durch die clientseitige Einstellung eines Empfangsfensters mit der Größe Null wird der Server daran gehindert, die Übertragung der Antworten abzuschließen und folglich die Routinen zur Speicherfreigabe zu aktivieren.

In diesem Szenario könnte ein nicht authentifizierter Remote-Benutzer die Schwachstelle sogar über einen einzigen Client mit begrenzter Bandbreite (z. B. 100 Mbit/s) ausnutzen: Dieser Verstärkungsmechanismus würde es ermöglichen, innerhalb weniger Sekunden schnell Dutzende Gigabyte RAM zu überlasten und so einen DoS-Angriff auf den Server durch einen Absturz oder eine Betriebsblockade zu verursachen. Der Angriff ist besonders effektiv, da er herkömmliche Perimeter- und Anwendungsschutzmaßnahmen umgeht, die auf der Überprüfung der maximalen Größe der Header basieren.

Betroffene Produkte und Versionen
-Webserver, die HTTP/2 verwenden, darunter:

Maßnahmen zur Risikominderung

Falls noch nicht geschehen, wird empfohlen, die Verfügbarkeit von Sicherheitsupdates für die verwendeten Produkte zu überprüfen, die das HTTP/2-Protokoll nutzen.

Für Produkte, für die noch keine spezifischen Updates verfügbar sind, wird empfohlen, in der Zwischenzeit die folgenden Abhilfemaßnahmen in Betracht zu ziehen:

• Deaktivieren Sie HTTP/2, sofern möglich
• Alternativ ein Zwischensystem (Proxy/WAF) einrichten, das strenge Beschränkungen hinsichtlich der Anzahl der Header pro Anfrage auferlegt

Um die Angriffsfläche auch bei Vorhandensein von Patches zu verringern:

• die maximale Anzahl von Headern pro Anfrage unabhängig von der Gesamtgröße begrenzen
• konfigurieren Sie zudem eine Begrenzung der Gesamtgröße der dekodierten Header (Hinweis: Die Begrenzungen für die Anzahl der Header und die Gesamtgröße müssen unabhängig voneinander konfiguriert werden, da der Angriff die Differenz zwischen diesen beiden Kontrollmechanismen ausnutzt)
• Verwalten Sie Cookies (Cookie-Crumbs), indem Sie diese in die Zählung der Header einbeziehen
• Timeouts für blockierte Streams festlegen, unabhängig von der Aktivität der WINDOW_UPDATE-Nachrichten
• den Speicher pro Prozess/Worker begrenzen (cgroups, ulimit -v, Container-Limits)
• ein frühzeitiges OOM-Kill der Worker fördern, damit diese im Falle eines Missbrauchs schnell neu gestartet werden
• verhindern, dass ein einzelner Worker zu viel Speicher verbraucht, um Auswirkungen auf das gesamte System (Swap oder CPU-/Speicherauslastung) zu vermeiden

[1] HPACK: Ein speziell für HTTP/2 entwickeltes Komprimierungsprotokoll für Metadaten (Header) (definiert in RFC 7541).

Referenzen

• https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb
• https://github.com/califio/publications/tree/main/MADBugs/http2-bomb
• https://www.openwall.com/lists/oss-security/2026/06/03/3

SOC