HTTP/2 Bomb (CVE-2026-49975): Wie ein Heimrechner Webserver lahmlegt

Das Wichtigste zuerst

Ein einzelner Rechner mit normaler Internetleitung kann verwundbare Webserver in Sekunden zum Absturz bringen. Die Angriffsklasse heißt HTTP/2 Bomb. Für Apache wird sie als CVE-2026-49975 geführt, betroffen sind aber auch nginx, Envoy und Microsoft IIS. Der Angriff nutzt keine exotische Lücke, sondern reguläre HTTP/2-Funktionen, die zusammen den Arbeitsspeicher des Servers fluten. Wer HTTP/2 betreibt, was bei TLS auf Port 443 oft die Voreinstellung ist, sollte die betroffenen Systeme jetzt prüfen.

Was passiert ist

Das Sicherheitsunternehmen Calif hat die Schwachstelle Anfang Juni 2026 öffentlich gemacht. Bemerkenswert ist der Weg dorthin: Die Forscher um Quang Luong setzten den KI-Agenten OpenAI Codex an, um aus öffentlichen Fehlerkorrekturen abzuleiten, wo ähnliche Muster in anderen Servern schlummern. Codex verkettete zwei lange bekannte Ideen zu einem neuen, wirksamen Angriff.

Seit dem 2. Juni 2026 liegt funktionsfähiger Proof-of-Concept-Code auf GitHub. Damit ist der Angriff praktisch für jeden reproduzierbar, der ihn einsetzen will.

Wie der Angriff funktioniert

Die HTTP/2 Bomb kombiniert zwei Bausteine. Exploit-Details lassen sich auf der Ebene des Prinzips erklären, ohne eine Anleitung zu liefern.

1. Die Kompressions-Bombe. HTTP/2 komprimiert Header mit dem Verfahren HPACK. Ein Angreifer legt einmal einen großen Header in der dynamischen HPACK-Tabelle ab und verweist anschließend tausendfach mit minimalem Aufwand darauf. Aus wenig Datenverkehr entstehen so riesige Header-Strukturen im Server. Das Prinzip ähnelt einer ZIP-Bombe, nur dass nicht eine entpackte Datei, sondern die dekomprimierten HTTP-Header den Speicher fluten. Ein Fehler in der Zählung aufgeteilter Cookie-Header ließ bei Apache zudem die übliche Obergrenze für Header-Felder umgehen.
2. Der Flow-Control-Hold. Danach setzt der Angreifer das Flusskontroll-Fenster der Verbindung auf null und sendet nur noch winzige WINDOW_UPDATE-Pakete. Der Server kann seine Antwort nie abschließen, hält die aufgeblähten Header aber im Speicher fest. Diese Slowloris-artige Technik pinnt die Allokation, bis der Speicher voll ist.

Das Ergebnis ist drastisch. In Tests von Calif und Radware reservierte ein einzelner Client mit 100 Mbit/s rund 32 Gigabyte Arbeitsspeicher auf Apache und Envoy in etwa 20 Sekunden. nginx und IIS wurden nach rund 45 Sekunden unerreichbar. Anders als bei volumetrischen Angriffen braucht es dafür kein Botnetz.

Welche Server betroffen sind

Die HTTP/2 Bomb ist eine Klasse, kein Einzelfehler. Der Patch-Stand unterscheidet sich je nach Produkt:

• Apache HTTP Server (CVE-2026-49975): betroffen sind 2.4.17 bis 2.4.67. Behoben in Version 2.4.68 beziehungsweise mod_http2 2.0.41.
• nginx: Die Versionen vor 1.29.8 hatten keine harte Obergrenze für die Anzahl der Header. Die neue Direktive max_headers begrenzt sie auf standardmäßig 1.000.
• Envoy (CVE-2026-47774): behoben in 1.35.11, 1.36.7, 1.37.3 und 1.38.1.
• Microsoft IIS / HTTP.sys (CVE-2026-49160): Fix über den Juni-Patchday, zusätzlich die Registry-Einstellung MaxHeadersCount.
• Cloudflare Pingora: in der Forschung als verwundbar genannt, ein öffentlicher Patch-Stand war zunächst unklar.

Reverse Proxies können schützen, wenn sie selbst nicht verwundbar sind und harte Header-Limits erzwingen. F5 stuft BIG-IP als nicht betroffen ein, weil es Anzahl und Größe dekodierter Header bereits begrenzt.

Die Einstufung der Schwere fällt unterschiedlich aus: CyCognito vergibt CVSS 7.5 (hoch), Red Hat bewertet die Lücken als wichtig, Apache selbst stuft sie als moderat ein, und die NVD-Bewertung war zum Redaktionsschluss noch offen. Maßgeblich ist daher weniger der einzelne Wert als die eigene Exposition.

Warum das für Unternehmen zählt

Ein Denial-of-Service-Angriff trifft nur die Verfügbarkeit, nicht die Vertraulichkeit von Daten. Für viele Betriebe ist genau das geschäftskritisch: Wenn Shop, Portal oder API stillstehen, entsteht direkter Schaden. Verfügbarkeit ist auch ein Pflichtthema in der NIS-2-Richtlinie.

Zwei Punkte machen die HTTP/2 Bomb besonders relevant. Erstens läuft HTTP/2 häufig per Default: Bei TLS-Deployments auf Port 443 ist es oft voraktiviert, ohne dass der Betreiber es bewusst eingeschaltet hat. Zweitens ist der Angriff protokollkonform: Er nutzt erlaubte Funktionen, weshalb klassische Netzwerkschutzmechanismen ihn schwer von normalem Verkehr unterscheiden.

Der KI-Bezug ist mehr als ein Detail. Sobald eine Fehlerkorrektur öffentlich ist, kann automatisierte Analyse ähnliche Schwächen im gesamten Ökosystem schneller aufspüren als manuelle Audits. Das verkürzt das Zeitfenster zwischen Bekanntwerden und Ausnutzung.

Was Sie diese Woche prüfen sollten

Konkret, ohne Aktionismus:

• Bestand klären: An welchen Stellen wird HTTP/2 terminiert? Das umfasst Origin-Server, Reverse Proxies, CDN, Loadbalancer und Ingress-Controller im Cluster. Wird HTTP/2 an einer WAF, einem CDN oder Cloud-Loadbalancer terminiert, zählt zuerst deren Patch-Stand: Eine vorgelagerte, nicht verwundbare Instanz mit harten Header-Limits schirmt die dahinterliegenden Server ab.
• Patchen: Apache auf 2.4.68, nginx auf 1.29.8, Envoy auf die genannten Versionen, IIS über den Juni-Patchday aktualisieren.
• Wo kein Patch möglich ist: HTTP/2 vorübergehend abschalten (Protocols http/1.1 bei Apache, http2 off; bei nginx). Das ist eine Notmaßnahme zum Überbrücken: Der Rückfall auf HTTP/1.1 kostet Multiplexing und damit Latenz, entfernt aber die Angriffsfläche.
• Limits erzwingen: Maximale Anzahl und Größe der Header getrennt begrenzen, Cookie-Bestandteile eingeschlossen, dazu die Zahl gleichzeitiger Streams je Verbindung.
• Speicher kappen: In Container-Umgebungen Memory-Limits für Proxy- und Gateway-Pods setzen, damit ein einzelner Prozess nicht den ganzen Host mitreißt.

Häufige Frage: Ist das nur ein Apache-Problem?

Nein. CVE-2026-49975 ist die Apache-Ausprägung, aber dieselbe Mechanik aus HPACK-Verstärkung und Flow-Control-Hold wurde gegen nginx, Envoy, Microsoft IIS und Cloudflare Pingora demonstriert. Wer nur Apache patcht, andere HTTP/2-Endpunkte aber übersieht, schließt die Lücke nur teilweise. Die Bedrohung gehört als Klasse betrachtet, nicht als einzelner CVE.

Einordnung

Die HTTP/2 Bomb reiht sich in bekannte Protokoll-Angriffe wie die HPACK Bomb (2016) und Rapid Reset (2023) ein und führt deren Prinzip weiter. Neu ist weniger die Technik als die Geschwindigkeit, mit der KI-gestützte Analyse solche Ketten findet und über Implementierungen hinweg überträgt. Für Betreiber bleibt die Antwort handfest: HTTP/2-Endpunkte kennen, patchen, Header- und Stream-Limits erzwingen. Web-Anwendungen und ihre vorgelagerten Server gehören regelmäßig in den Prüfumfang eines Penetrationstests für Webanwendungen. Einzelne Patch-Stände, etwa bei Pingora, waren zum Zeitpunkt der Veröffentlichung noch in Bewegung, weshalb ein Blick auf die Herstellerhinweise lohnt.

Autor: Chris Wojzechowski, Geschäftsführer AWARE7, IT-Sicherheit. Quellen: Calif (Original-Analyse), NVD, Red Hat, CyCognito, Radware, F5, GovCERT Hong Kong sowie die nginx-Dokumentation.