Zum Hauptinhalt springen
S-EDV news
← Alle News
Server & Netzwerk 04.06.2026 · 4 min Lesezeit

HTTP/2 Bomb (CVE‑2026‑49975): Kritische DoS-Lücke trifft nginx, Apache, IIS und Envoy

CVE-2026-49975 „HTTP/2 Bomb" (CVSS 9,8) nutzt HPACK-Kompressions-Amplifikation, um Server in Sekunden lahmzulegen. Patches gibt es bisher nur für nginx 1.29.8 und Apache mod_http2 2.0.41 – IIS, Envoy und Pingora sind noch ungepatcht.

Symbolbild HTTP/2 Bomb DoS-Angriff auf Webserver

Am 3. Juni 2026 haben Sicherheitsforscher koordiniert eine schwerwiegende Denial-of-Service-Schwachstelle offengelegt, die unter dem Namen HTTP/2 Bomb bekannt geworden ist. Die als CVE-2026-49975 registrierte Lücke erreicht einen CVSS-Score von 9,8 (Kritisch) und betrifft nahezu alle weit verbreiteten Webserver-Implementierungen mit aktiviertem HTTP/2: nginx, Apache httpd, Microsoft IIS, Envoy Proxy und Cloudflare Pingora. Entdeckt wurde die Technik vom Offensiv-Sicherheitsunternehmen Calif, das dabei einen KI-Agenten auf Basis von OpenAI Codex einsetzte. Forscher Quang Luong soll die Ergebnisse auf der Real World AI Security-Konferenz an der Stanford University vorstellen. Ein öffentlich verfügbarer Proof-of-Concept-Code erhöht den Handlungsdruck erheblich.

Die Schwachstelle: HPACK-Amplifikation trifft Slowloris

Die HTTP/2 Bomb kombiniert zwei etablierte Angriffsprinzipien zu einer besonders effizienten Waffe. Das HTTP/2-Protokoll verwendet HPACK-Kompression für Header-Felder, um Bandbreite zu sparen. Ein Angreifer kann diese Kompressionstabellen jedoch gezielt manipulieren und extrem viele Header mit einem einzigen komprimierten Byte referenzieren. Gleichzeitig hält er die Verbindung nach Art eines Slowloris-Angriffs offen, ohne sie abzuschließen, sodass der Server kontinuierlich Speicher reserviert, ohne ihn freizugeben.

Das Ergebnis sind extreme Amplifikationsverhältnisse: Envoy Proxy erschöpft 32 GB RAM in rund 10 Sekunden (Verhältnis 5.700:1), Apache httpd benötigt etwa 18 Sekunden (4.000:1), nginx rund 45 Sekunden, und Microsoft IIS legt 64 GB in ungefähr 45 Sekunden lahm. Ein einzelner Angreifer mit einem normalen Heimanschluss kann diesen Angriff ohne Authentifizierung ausführen. Zum Zeitpunkt der Offenlegung waren laut einem Shodan-Scan mehr als 880.000 öffentlich erreichbare Server exponiert. CVE-2026-49975 wurde spezifisch für die Apache-httpd-Variante vergeben; für andere betroffene Produkte können separate CVEs folgen oder sich in Bearbeitung befinden.

Bin ich betroffen?

Alle Systeme, die HTTP/2 in der Standardkonfiguration aktiviert haben, sind potenziell gefährdet. Die folgende Tabelle gibt einen Überblick über betroffene Produkte und den aktuellen Patch-Stand:

ProduktBetroffene VersionenRAM-ErschöpfungPatch verfügbar
nginxAlle Versionen vor 1.29.832 GB in ~45 sJa – Version 1.29.8
Apache httpd (mod_http2)mod_http2 vor 2.0.4132 GB in ~18 sJa – mod_http2 2.0.41
Microsoft IISAlle aktuellen Versionen64 GB in ~45 sNein (Stand 3. Juni 2026)
Envoy ProxyAlle aktuellen Versionen32 GB in ~10 sNein (Stand 3. Juni 2026)
Cloudflare PingoraAlle aktuellen Versionennicht spezifiziertNein (Stand 3. Juni 2026)

Administratoren können prüfen, ob HTTP/2 auf ihrem nginx-Server aktiv ist, indem sie die Konfiguration auf http2-Direktiven untersuchen:

nginx -T | grep -i http2

Auf einem Apache-System mit mod_http2 zeigt der folgende Befehl den Modulstatus:

apachectl -M | grep http2

Wie behebe ich das?

nginx: Ein Update auf Version 1.29.8 oder neuer behebt die Schwachstelle. Diese Version führt eine neue max_headers-Direktive ein, die standardmäßig auf 1.000 Header begrenzt ist und so die Amplifikation verhindert. Die grundlegende Vorgehensweise bei nginx-Konfiguration beschreibt die Anleitung nginx als Reverse Proxy mit TLS einrichten auf s-edv.com.

Apache httpd: Das Update auf mod_http2 2.0.41 oder neuer schließt die Lücke. Die verantwortliche Disclosure erfolgte bereits am 27. Mai 2026, der Patch wurde am selben Tag eingecheckt.

Microsoft IIS, Envoy Proxy, Cloudflare Pingora: Da noch kein Patch verfügbar ist, empfehlen die Forscher zwei Sofortmaßnahmen:

  • HTTP/2 deaktivieren, bis ein Patch verfügbar ist – dies reduziert die Performance, beseitigt aber das unmittelbare Risiko vollständig.
  • Vorgelagerten Reverse Proxy oder WAF mit harten Header-Count-Limits einsetzen, der eingehende HTTP/2-Verbindungen auf eine maximale Header-Anzahl beschränkt, bevor Anfragen den eigentlichen Server erreichen. Hinweise zur Absicherung eines Linux-Servers bietet die Anleitung Linux-Server absichern mit ufw und fail2ban.

Da öffentlicher PoC-Code verfügbar ist und kein Authentifizierungserfordernis für Angreifer besteht, sollten diese Maßnahmen unmittelbar umgesetzt werden.

Was bedeutet das für Unternehmen?

Die HTTP/2 Bomb stellt eine unmittelbare Bedrohung für jeden Betreiber öffentlich erreichbarer Webserver dar. Besonders kritisch ist die Lage für E-Commerce-Plattformen, SaaS-Anbieter und API-Gateways, die auf Envoy basieren oder Microsoft IIS einsetzen – bei diesen Produkten fehlt der Patch noch. Da ein einzelner Angreifer ohne besondere technische Ressourcen oder Botnetz einen Server innerhalb weniger Sekunden außer Betrieb setzen kann und PoC-Code öffentlich zugänglich ist, muss mit aktiven Angriffen in Kürze gerechnet werden.

Für Unternehmen mit gepatchtem nginx oder Apache sollte das Update mit hoher Priorität eingespielt werden – idealerweise als Notfallpatch außerhalb des regulären Wartungsfensters. Wer IIS, Envoy oder Pingora betreibt, sollte die Deaktivierung von HTTP/2 als temporäre Maßnahme unmittelbar in Betracht ziehen und die Hersteller-Kommunikation zu Patches engmaschig verfolgen. Ein strukturierter Notfallplan für den Fall eines erfolgreichen DoS-Angriffs, wie ihn die Anleitung Ransomware-Notfallplan: Die ersten 60 Minuten beschreibt, kann auch in diesem Kontext wertvolle Orientierung bieten.

Die Entdeckung durch einen KI-Agenten unterstreicht eine zunehmende Tendenz: Angriffsflächen, die menschliche Forscher bislang übersehen haben, werden künftig schneller durch automatisierte Werkzeuge aufgedeckt – sowohl von der verteidigenden als auch von der angreifenden Seite.

Quellen: SecurityWeek | The Hacker News | BleepingComputer | oss-security (Openwall) | Tenable CVE Record | GBHackers