3. Juni 2026 13 Min. Lesezeit

Hoch

Von

Kai Ole Hartwig

HTTP/2 Bomb: ein Wire-Byte, ~4.000 Byte Server-Speicher — die von Codex entdeckte Remote-DoS gegen nginx, Apache, IIS, Envoy und Pingora

2. Juni 2026. Calif hat die HTTP/2 Bomb veröffentlicht: eine Remote-Denial-of-Service, die in der Standardkonfiguration von nginx, Apache httpd, Microsoft IIS, Envoy und Cloudflare Pingora steckt und zwei je rund zehn Jahre alte Techniken zu etwas Neuem verkettet. Eine HPACK-Indexed-Reference-Bombe verwandelt ein einzelnes Wire-Byte in bis zu ~4.000 Byte Server-Speicher, und ein HTTP/2-Window-Stall hält jede dieser Allokationen quasi gratis beliebig lange fest; ein Heim-PC an 100 Mbit/s reicht, um gegen Apache oder Envoy in rund 20 Sekunden ~32 GB zu binden. Entdeckt hat die Verkettung der KI-Coding-Agent Codex, und ein vollständiger, dockerisierter PoC für alle fünf Server ist öffentlich. nginx ist in 1.29.8 behoben, Apache im Trunk; für IIS, Envoy und Pingora gab es zum Veröffentlichungszeitpunkt keinen Patch.

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?: HTTP/2 Bomb (Calif, 02.06.2026), eine Remote-DoS gegen die Default-HTTP/2-Konfiguration mehrerer großer Webserver. Mechanismus: HPACK Indexed Reference Bomb (Verstärkung: 1 Wire-Byte → ~70 bis ~4.000 Byte Server-Allokation pro Referenz) verkettet mit einem HTTP/2 Window Stall (Zero-Byte-Flow-Control-Window + 1-Byte-WINDOW_UPDATE-Drip, der die Allokationen im Speicher festhält).
Wie schwer?: Hoch. Speicher-Erschöpfung aus der Ferne, Default-Config betroffen, öffentlicher PoC. Gegen Apache httpd und Envoy hält ein einzelner Client ~32 GB in rund 20 Sekunden; ein Heim-PC an 100 Mbit/s genügt. DoS, kein Code-Execution.
Welche Server sind betroffen?: nginx (1.29.7, ~70:1), Apache httpd (2.4.67, ~4.000:1), Microsoft IIS (Windows Server 2025, ~68:1), Envoy (1.37.2, ~5.700:1), Cloudflare Pingora (0.8.0, ~62:1 laut PoC-Repo). Go-basierte Server (Caddy, Traefik) sind nach unserer Quellcode-Analyse strukturell weitgehend geschützt (siehe FAQ).
Bin ich als Moselwal-Kunde betroffen?: Betroffen, wenn Sie einen der genannten Server mit aktiviertem HTTP/2 (h2) öffentlich erreichbar betreiben und noch nicht gepatcht/mitigiert haben. Hinter einem robusten CDN ist die Lage deutlich entschärft. Reine HTTP/1.1-Endpunkte und Go-basierte Proxies sind nicht das primäre Ziel.
Sofort-Mitigation?: nginx: auf 1.29.8+ heben (max_headers, Default 1000) oder http2 off;. Apache: Protocols http/1.1 als Workaround (der mod_http2-Fix liegt im Trunk, ein fertiges 2.4.x-Release steht noch aus). IIS/Envoy/Pingora: HTTP/2 deaktivieren oder einen Proxy mit hartem Header-Count-Cap davorsetzen. Generell: Per-Worker-Memory cappen (cgroups, ulimit -v).
Kritikalität?: Siehe Hero-Badge high. Public PoC und triviale Eintrittsschwelle erhöhen den Druck; keine bestätigte aktive Massen-Ausnutzung Stand 02.06.

Was ist passiert

Am 2. Juni 2026 hat Calif (Thai Duong) unter dem Titel „Codex Discovered a Hidden HTTP/2 Bomb“ eine Remote-Denial-of-Service gegen die meisten großen Webserver veröffentlicht: nginx, Apache httpd, Microsoft IIS, Envoy und Cloudflare Pingora. Das verwundbare Verhalten steckt jeweils in der Standard-HTTP/2-Konfiguration, nicht in einer exotischen Sonderoption.

Der Angriff ist eine Verkettung zweier seit etwa zehn Jahren einzeln bekannter Techniken. Die erste ist eine HPACK-Indexed-Reference-Bombe: HPACK (RFC 7541) komprimiert HTTP/2-Header über eine dynamische Tabelle, in die ein Sender einen Header einmal einträgt und danach per Index (meist ein einziges Byte) referenziert. Der Angreifer trägt einen Header ein und feuert dann tausende 1-Byte-Indexreferenzen darauf. Jede kostet ihn ein Byte auf der Leitung, den Server aber eine volle Header-Allokation: laut Quelle ~70 Byte bei nginx, IIS und Pingora, bis zu ~4.000 Byte bei Apache httpd und Envoy.

Die zweite Technik ist der HTTP/2 Window Stall. HTTP/2 (RFC 9113) hat eine Flow-Control, bei der der Empfänger ein Fenster annonciert; entscheidend ist, dass der Client das Fenster für die Server-Antwort kontrolliert. Der Angreifer annonciert ein Zero-Byte-Window, sodass der Server seine Antwort nie fertig senden kann, und tropft dann 1-Byte-WINDOW_UPDATE-Frames nach, die jeweils den Send-Timeout zurücksetzen. So bleibt jede allokierte Zelle so lange im Speicher gepinnt, wie der Server-Timeout erlaubt.

Die Wirkung ist drastisch: Gegen Apache httpd und Envoy bindet ein einzelner Client rund 32 GB in etwa 20 Sekunden, ein Heim-PC an 100 Mbit/s macht einen verwundbaren Server „innerhalb von Sekunden“ unerreichbar. Eine Shodan-Suche der Autoren ergab über 880.000 Websites mit HTTP/2 auf einem dieser Server, wobei viele hinter einem CDN sitzen und damit schwerer angreifbar sind. Bemerkenswert ist die Herkunft: Die Verkettung hat nicht ein Mensch gefunden, sondern der KI-Coding-Agent Codex, der die Codebasen las und erkannte, dass die beiden Bausteine komponieren.

Technische Einordnung

Das eigentlich Neue an der HTTP/2 Bomb ist nicht die Verstärkung an sich — HPACK-Bomben gibt es seit 2016. Neu ist, woher die Verstärkung kommt. Die klassische Bombe stopft einen großen Wert in die Tabelle und referenziert ihn, weshalb Server gelernt haben, die decodierte Gesamt-Headergröße zu begrenzen. Diese Variante geht umgekehrt vor: Der Header ist fast leer, und die Verstärkung entsteht aus dem Per-Entry-Bookkeeping, das der Server pro Eintrag drumherum allokiert. Das „maximum decoded header size“-Limit feuert nie, weil es fast nichts zu decodieren gibt. Die Lücke sitzt also genau im blinden Fleck der etablierten Abwehr.

Der zweite konzeptionelle Punkt ist die Trennung von Ratio und Zeit. Die Autoren formulieren es treffend: „Ratio ist nur die halbe Gleichung.“ Eine 70:1-Verstärkung wäre harmlos, wenn der Speicher bei Request-Ende freigegeben würde. Zur Waffe wird sie erst durch den Window-Stall, der die Verbindung quasi gratis offenhält und jede allokierte Zelle pinnt. Genau deshalb genügen bei nginx (nur ~70:1) trotzdem Sekunden bis Minuten, um Gigabytes zu binden — die Zeitachse trägt, was die Ratio allein nicht schafft.

Der dritte Punkt erklärt, warum die Verstärkung bei Apache und Envoy so viel höher ausfällt: das Cookie-Crumb-Splitting. Server, die statt der Größe die Header-Feld-Anzahl begrenzen, umgeht man über den Cookie-Header: RFC 9113 §8.2.3 erlaubt ausdrücklich, ihn in ein Feld pro Crumb zu splitten, und diese Server zählten die Crumbs nicht gegen ihr Limit. Envoy hängt jeden Crumb an einen Puffer (ein fetter Cookie, vieltausendfach referenziert, ergibt bis ~5.700:1 auf einem Stream); Apache baut bei jedem Crumb den gesamten gemergten String neu und lässt die alten Kopien bis zum Cleanup leben, was selbst mit leerem Cookie ~4.000:1 erzeugt. Die tiefere Lehre der Autoren: Wenn fünf unabhängige Implementierungen denselben Bug-Typ ausliefern, liegt der Defekt in der Spezifikation — RFC 7541 §7.3 hält das Memory-Risiko für mit SETTINGS_HEADER_TABLE_SIZE erledigt und übersieht das Bookkeeping plus die Zeitachse.

Wer ist betroffen

Betroffen	Nicht / kaum betroffen	Bedingung
nginx < 1.29.8, Apache httpd 2.4.x (mod_http2), Microsoft IIS, Envoy, Cloudflare Pingora — jeweils mit aktivem HTTP/2 (h2)	Reine HTTP/1.1-Endpunkte; Server mit hartem Header-Count-Cap inkl. Cookie-Crumbs und gebundener Stalled-Stream-Lebenszeit	HTTP/2 aktiv und Server in der betroffenen Liste/Version
Direkt aus dem Internet erreichbare Instanzen der betroffenen Server	Instanzen hinter einem robusten CDN (laut Quelle „much harder to bring down“)	Erreichbarkeit / CDN-Vorschaltung
Envoy im Kubernetes-Ingress/Service-Mesh, Apache/nginx als Reverse-Proxy vor Anwendungen	Go-basierte Server (Caddy, Traefik) — strukturell weitgehend geschützt (siehe FAQ), Stall-Teilrisiko bei Default-Timeouts	HTTP/2-Stack-Implementierung

Die schnellste Triage: Betreiben Sie einen der fünf Server mit aktivem HTTP/2, der direkt aus dem Internet erreichbar ist? Dann ist der Pfad relevant. Ein vorgeschaltetes, robustes CDN oder ein reiner HTTP/1.1-Betrieb entschärft die Lage erheblich.

Auswirkungen und Sofortmaßnahmen

Die Auswirkung ist Speicher-Erschöpfung aus der Ferne: ein einzelner Client kann genug Server-Speicher binden, um die Maschine in den Swap zu drücken oder Worker per OOM zu killen. Die Autoren weisen auf eine besonders unangenehme Spielart hin: Statt das Prozess-OOM auszulösen (ein gekillter Worker respawnt sauber), hält ein Angreifer den Speicherdruck knapp unter der Kill-Schwelle und lässt jeden anderen Request auf der Maschine im Swap verhungern. Für Mehrmandanten-Hosts und geteilte Ingress-Schichten ist das ein Verfügbarkeits- und damit NIS-2-Thema (Art. 21, Aufrechterhaltung des Betriebs).

Operational Decision Block

Sofort handeln, wenn: ein betroffener Server mit aktivem HTTP/2 direkt aus dem Internet erreichbar ist und nicht hinter einem robusten CDN sitzt.
Im Wartungsfenster, wenn: der Server hinter einem CDN/WAF mit hartem Header-Count-Cap steht — der akute Hebel ist kleiner, der Patch bleibt Pflicht.
Kein akuter Druck, wenn: Sie ausschließlich HTTP/1.1 ausliefern oder einen Go-basierten Server (Caddy, Traefik) einsetzen — kurz die Stalled-Stream-Timeouts prüfen und abhaken.

In dieser Reihenfolge. Erstens, nginx auf 1.29.8+ heben (bringt die max_headers-Direktive, Default 1000) oder, wenn das nicht sofort geht, HTTP/2 mit http2 off; deaktivieren. Zweitens, Apache absichern: Da der mod_http2-Fix zum Veröffentlichungszeitpunkt nur im Trunk liegt und kein fertiges 2.4.x-Release bereitsteht, ist Protocols http/1.1 der realistische Sofort-Workaround; LimitRequestFieldSize zu senken wirkt nur teilweise, LimitRequestFields zu senken bringt hier nichts (die Cookie-Crumbs zählten nicht dagegen). Drittens, IIS/Envoy/Pingora: HTTP/2 deaktivieren oder einen vorgelagerten Proxy mit hartem Header-Count-Cap pro Request einsetzen. Viertens, als Auffangnetz Per-Worker-Memory cappen (cgroups, ulimit -v, Container-Limits), damit ein bombardierter Worker früh OOM-gekillt und neu gestartet wird, bevor er die Maschine in den Swap zieht.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Detection / Prüfung

Lead. Zwei Ebenen: „bin ich verwundbar“ (Versions- und Konfig-Frage) und „werde ich gerade angegriffen“ (Laufzeit-Signal). Das verräterische Laufzeit-Muster ist eine Kombination aus stark steigendem Speicher (RSS) eines Worker-Prozesses und HTTP/2-Streams, die offen bleiben, ohne dass die Antwort abfließt.

Prüf-Snippets (Copy/Paste):

# 1) Versionen feststellen
nginx -v            # < 1.29.8 = anfällig, falls http2 aktiv
httpd -v            # Apache 2.4.x mit mod_http2
envoy --version

# 2) Ist HTTP/2 (h2) öffentlich aktiv? ALPN gegen den eigenen Endpoint prüfen
openssl s_client -alpn h2 -connect example.org:443 </dev/null 2>/dev/null \
  | grep -i 'ALPN'

# 3) nginx: max_headers gesetzt? (ab 1.29.8 verfügbar)
nginx -T 2>/dev/null | grep -i 'max_headers\|http2'

# 4) Laufzeit: Worker-RSS beobachten (Spikes unter Last)
ps -o pid,rss,cmd -C nginx --sort=-rss | head
ps -o pid,rss,cmd -C httpd --sort=-rss | head

# 5) Per-Worker-Memory-Cap als Auffangnetz (systemd-Unit)
#    MemoryMax=1G  in der [Service]-Sektion, dann: systemctl daemon-reload && restart

Was auffällig ist: ein einzelner Client (eine Source-IP / wenige Connections), der viele HTTP/2-Streams öffnet, die nicht abgeschlossen werden, bei gleichzeitig schnell wachsendem Worker-RSS. Da die Bombe mit minimalem Upload arbeitet, ist ein hoher Speicher-pro-eingehendem-Byte-Quotient das Kernsignal — klassische Volumen-basierte DoS-Erkennung greift hier schlecht.

Betreiberempfehlung

Mittelstand

Für TYPO3-/Anwendungs-Hosting hinter nginx ist das schnellste der saubere Schritt: auf nginx 1.29.8+ heben, max_headers bleibt dann beim Default 1000. Wer Apache mit mod_http2 fährt, setzt bis zum 2.4.x-Release Protocols http/1.1 als Workaround — der Verlust an HTTP/2 ist für die meisten Standard-Sites verkraftbar und in Tagen, nicht Wochen, rückgängig zu machen. Wer ein CDN vorgeschaltet hat, prüft, ob dieses einen harten Header-Count-Cap pro Request erzwingt.

Container / Kubernetes

Envoy als Ingress oder Sidecar ist der heikelste Fall (höchste Verstärkung, kein Patch zum Veröffentlichungszeitpunkt). Hier gilt: vorgelagerte Schicht mit hartem Header-Count-Cap, HTTP/2-Terminierung bewusst wählen, und in jedem Fall Per-Pod-Memory-Limits setzen, damit ein bombardierter Pod neu gestartet wird, statt den Node in den Swap zu ziehen. Den Versionssprung einplanen, sobald Envoy einen Fix veröffentlicht.

Hosting & Betrieb

Die strukturelle Lehre für jede HTTP/2-Terminierung: Es braucht beide Limits („maximum decoded header size“ UND „maximum header count“, inklusive Cookie-Crumbs) plus eine gebundene Lebenszeit für stehengebliebene Streams, unabhängig von WINDOW_UPDATE-Aktivität. Wo das heute nicht geht, ist der Per-Worker-Memory-Cap das pragmatische Auffangnetz: Ein früh gekillter, sauber respawnter Worker ist die bessere Failure-Mode als eine bei 95 % Speicher festgehaltene Maschine.

Häufige Fragen zur HTTP/2 Bomb

Gibt es einen funktionierenden Exploit?+

Ja. Calif hat ein vollständiges, dockerisiertes PoC-Kit für alle fünf Server veröffentlicht (Exploit-Skripte, Lab-Targets, RSS-Monitore, Demos) inklusive ausdrücklichem Hinweis „Please don't point these at infrastructure you don't own.“ Das verkürzt den Weg von Disclosure zu Angriff drastisch — die Mitigation gehört entsprechend nach vorn.

Warum hilft LimitRequestFields bei Apache nicht?+

Weil die Cookie-Crumbs, über die der Angriff läuft, nicht gegen LimitRequestFields gezählt wurden — genau das ist der Bypass. Der eigentliche Fix (mod_http2 v2.0.41, derzeit nur im Trunk) lässt gemergte Cookies als „add“ gegen das Limit zählen. Bis ein 2.4.x-Release da ist, ist Protocols http/1.1 der wirksame Workaround; LimitRequestFieldSize zu senken ist nur eine Teil-Mitigation.

Wie prüfe ich, ob mein nginx verwundbar ist?+

Version gegen 1.29.8 abgleichen (nginx -v) und prüfen, ob HTTP/2 aktiv ist. Unter 1.29.8 ohne max_headers ist der Pfad offen, sobald h2 läuft. Schnellster Fix: auf 1.29.8+ heben (Default max_headers 1000); Notnagel: http2 off;.

Reicht es, hinter einem CDN zu sitzen?+

Es entschärft erheblich — die Autoren schreiben selbst, CDN-fronted Instanzen seien „much harder to bring down“. Voraussetzung ist, dass das CDN einen harten Header-Count-Cap pro Request (inklusive Cookie-Crumbs) erzwingt und stehengebliebene Streams begrenzt. Der Origin-Server gehört trotzdem gepatcht: Wer den Origin direkt erreichen kann (Origin-IP bekannt, interne Pfade), umgeht das CDN.

Gilt das auch für Traefik und andere Go-Server?+

Ja, im Kern. Traefik nutzt denselben Go-net/http2-Stack und profitiert von derselben Per-Feld-Buchführung inklusive Cookie-Crumbs. Der gemeinsame Restvorbehalt ist die Stalled-Stream-Lebenszeit: Setzen Sie sinnvolle Write-/Idle-Timeouts (bzw. WriteByteTimeout), damit ein gehaltener Stream nicht unbegrenzt offenbleibt. Eine Kuriosität am Rande: Eine kursierende Zusammenfassung behauptete, Caddy/Traefik seien „direkt betroffen“ und verwies auf Go-Versionen 1.22.2/1.21.9 — das verwechselt diese Bombe mit dem älteren HTTP/2 Rapid Reset (CVE-2023-44487) und ist für diese Lücke nicht belegt.

Ist Caddy von der HTTP/2 Bomb betroffen?+

Nach unserer Quellcode-Analyse von Gos net/http2 (das Caddy nutzt) ist Caddy gegen die schädliche Verstärkung strukturell weitgehend geschützt. Go zählt pro Header-Feld len(Name)+len(Value)+32 Byte gegen ein Budget (Default MaxHeaderBytes = 1 MB) und reißt die Verbindung bei Überschreitung ab — die +32-Byte-Pauschale pro Feld macht aus dem Größenlimit faktisch ein Feld-Anzahl-Limit, und sie gilt auch für jeden einzelnen Cookie-Crumb, bevor irgendetwas gemergt wird. Genau diese Abwehr fehlte nginx/Apache/Envoy. Der Window-Stall-Teil ist bei Go/Caddy-Defaults zwar nur schwach begrenzt (WriteByteTimeout ist standardmäßig aus), aber ohne den Verstärker pinnt ein gehaltener Stream nur ~1 MB statt Gigabytes. Transparenz-Hinweis: Diese Einordnung beruht auf direkter Quellcode-Analyse von server.go, frame.go und hpack.go, nicht auf einem von uns durchgeführten PoC-Lauf: Caddy taucht weder im calif.io-Blog noch im PoC-Repo auf. Wir formulieren deshalb „strukturell weitgehend geschützt“, nicht „getestet sicher“; die Quellcode-Evidenz spricht aber klar für „geschützt“.

Fazit

Die HTTP/2 Bomb ist ein Lehrstück über zwei Dinge. Erstens technisch: Eine Schwachstelle muss nicht neu sein, um gefährlich zu werden; es genügt, zwei alte, je für sich gebändigte Bausteine zu kombinieren, bis sie im blinden Fleck der etablierten Abwehr zusammenfallen. Die Verstärkung aus dem Per-Entry-Bookkeeping plus das kostenlose Festhalten über den Window-Stall ergeben eine Remote-DoS, die in der Default-Config steckt und mit einem Heim-PC auslösbar ist. Zweitens betrieblich: Die Triage ist billig (Version, ALPN, RSS-Beobachtung), die Sofort-Maßnahmen sind bekannt (nginx-Upgrade, Protocols http/1.1, Memory-Cap), und wer Go-basiert (Caddy, Traefik) fährt, ist strukturell besser dran, sollte aber die Stalled-Stream-Timeouts prüfen. Risiko nüchtern: hoch für direkt erreichbare, ungepatchte nginx/Apache/IIS/Envoy/Pingora mit aktivem HTTP/2; deutlich kleiner hinter robustem CDN, bei reinem HTTP/1.1 oder im Go-Stack. Die unbequemste Begleitnachricht ist die Geschwindigkeit: Eine KI fand die Verkettung, und öffentliche Fix-Diffs lassen sich heute schnell in Exploits übersetzen — das Wartungsfenster zwischen Patch und Massen-Ausnutzung schrumpft.

Quellen

Über den Autor

Kai Ole Hartwig

Founder · Moselwal Digitalagentur · OnlyOle

Programmiert seit 2002 – autodidaktisch gelernt, 2012 mit KO-Web selbständig gemacht, heute Moselwal. Über 100 Projekte, Fokus auf Security, Performance, Automatisierung und Qualität.

LinkedIn · GitHub · Blog · OnlyOle