HTTP/2 Bomb: HPACK Indexed-Reference Amplification Chain Attack

Eine unabhängige technische Tiefenanalyse eines Oberschülers
Juni 2026

TL;DR

Dieses Repository enthält meine vollständige Analyse der HTTP/2 Bomb-Sicherheitslücke (CVE-2026-49975 / CVE-2026-47774), die zwei jahrzehntealte HTTP/2-Primitiven miteinander verknüpft:

• HPACK indexed-reference amplification – Senden tausender Ein-Byte-Referenzen auf einen fast leeren dynamischen Tabelleneintrag
• Flow-control window stall – Null-Anfangsfenster + periodisches 1-Byte-WINDOW_UPDATE, um Speicher dauerhaft zu belegen

Ergebnis: Ein einzelner 100-Mbps-Client kann 32 GB Serverspeicher in nur 10 Sekunden erschöpfen.

🧠 Wie ich darauf gekommen bin

Alles begann, während ich auf Bilibili (Chinas YouTube) doom‑scrolled. Ein Tech-Kanal erwähnte kurz „einen neuen HTTP/2-Angriff, der große Webserver lahmlegt.“ Keine Details, nur die Schlagzeile.

Das hat mich gepackt. Ich pausierte das Video, öffnete den Offenlegungslink und fiel in ein Kaninchenloch. Ein Papier führte zu fünf CVEs, zu RFCs, zum Quellcode. Ich hörte nicht auf, bis ich genau verstand, warum ein einzelnes Byte auf der Leitung 59 Bytes Speicher blockieren konnte – und warum niemand zuvor die beiden Tricks miteinander kombiniert hatte.

Dieses Repo ist also nicht nur eine Zusammenfassung. Es ist mein vollständiger, kompromissloser Deep‑Dive, von Grund auf in LaTeX geschrieben. Kein Lehrer hat mich darum gebeten. Ich konnte einfach nicht loslassen.

Auswirkungen

Betrifft Standardkonfigurationen aller fünf großen Webserver-Implementierungen:

Inhalt

Chinesischer Blogbeitrag (laienverständlich):
https://www.itedev.com/posts/2026/06/12/http2-bomb-blog-zh

Wichtigste Erkenntnisse (Unabhängig)

1. Die Verstärkung entsteht durch Verwaltungsaufwand pro Eintrag (Pool-Blöcke, Strukturen), nicht durch die decodierte Größe – umgeht traditionelle HPACK-Bomben-Abwehrmaßnahmen.
2. Die Zusammenführung von Cookie-Crumbs in Apache führt zu quadratischem Speicherwachstum O(N²).
3. Envoys Cookie-Puffer umgeht max_request_headers_kb – bis zu 5.700-fache Verstärkung.
4. RFC 7541 §7.3 Spezifikationsfehler: modelliert nur das Kompressionsverhältnis, nicht Verwaltungsaufwand pro Eintrag + Flow-Control-Pinning.

Abwehrmodell

„Maximale decodierte Headergröße“ und „maximale Headeranzahl“ sind zwei unterschiedliche Grenzen, und ein Server benötigt beide.

Warum das wichtig ist

Diese Sicherheitslücke wurde von KI (Codex) entdeckt, die gleichzeitig fünf Codebasen durchforstete – eine neue Klasse von implementierungsübergreifenden Protokollschwachstellen, bei denen „niemand die Nahtstellen besitzt“.

Basierend auf

Koordinierte Offenlegung durch Quang Luong, Jun Rong, Duc Phan (Calif Security Research), 2. Juni 2026.
Originalpapier: blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

Autor

Zhicheng Wu
Xinhui No.1 Mittelschule, Jahrgang 2028
Guangdong, China

Lizenz

Dieses Werk ist lizenziert unter CC BY 4.0.
Sie dürfen teilen und anpassen, mit Namensnennung.

---

Nur für akademische und defensive Zwecke.