HTTP/2 Bomb: Webserver-Lücke trifft Apache und nginx
Sie befinden sich: Home > News Archiv > Webmaster > HTTP/2 Bomb: Webserv...
Ein einzelner Heim-PC mit normaler Leitung genügt, um einen Webserver in Sekunden lahmzulegen. Die HTTP/2 Bomb trifft Apache, nginx, IIS und sogar Cloudflare. Wer HTTP/2 aktiviert hat, sollte diese Woche handeln.Ein Rechner. Eine normale Internetleitung. Mehr braucht ein Angreifer nicht, um einen Webserver in Sekunden in die Knie zu zwingen. Kein Botnet, keine gemieteten Server, keine ausgefeilte Infrastruktur. Die Sicherheitsfirma Calif hat Anfang Juni 2026 einen Angriff veröffentlicht, der genau das schafft, und ihn passend "HTTP/2 Bomb" getauft.
Betroffen sind nicht ein oder zwei Nischenprodukte, sondern faktisch jeder große Webserver: Apache, nginx, Microsoft IIS, Envoy und sogar Cloudflares Pingora. Wenn Ihre Seite HTTP/2 spricht, und das tun heute die allermeisten, sollten Sie diese Woche aktiv werden.
Was die HTTP/2 Bomb so gefährlich macht
Klassische Überlastungsangriffe brauchen Masse. Hunderte oder tausende Rechner feuern gleichzeitig, bis ein Server aufgibt. Die HTTP/2 Bomb dreht dieses Verhältnis um: Der Angreifer schickt wenige Bytes, der Server reserviert dafür Gigabyte an Arbeitsspeicher.
In der Demonstration von Calif belegte ein einziger Client rund 32 Gigabyte Server-Speicher in etwa 20 Sekunden. Gegen manche Konfigurationen reicht eine 100-Mbit-Leitung, wie man sie zu Hause hat. Wie stark der Hebel ausfällt, hängt vom Server ab:
| Webserver | Verstärkung | Wirkung im Test |
|---|---|---|
| Envoy 1.37.2 | rund 5.700:1 | etwa 32 GB in 10 Sekunden |
| Apache 2.4.67 | rund 4.000:1 | etwa 32 GB in 18 Sekunden |
| nginx 1.29.7 | rund 70:1 | etwa 32 GB in 45 Sekunden |
| Microsoft IIS (Server 2025) | rund 68:1 | etwa 64 GB in 45 Sekunden |
Ein Scan über den Suchdienst Shodan fand mehr als 880.000 Websites, die HTTP/2 nutzen und einen dieser Server einsetzen. Ein Teil davon sitzt hinter einem CDN und ist dadurch schwerer direkt erreichbar. Der Rest steht offen.
Drei Lücken, die ständig verwechselt werden
In den Meldungen tauchen mehrere CVE-Nummern auf, und sie meinen nicht dasselbe. Wer hier durcheinanderkommt, patcht am Ende das Falsche. Diese drei sollten Sie auseinanderhalten:
| Schwachstelle | Betrifft | Schweregrad | Behoben in |
|---|---|---|---|
| CVE-2026-49975 (HTTP/2 Bomb, Apache) | Apache 2.4.17 bis 2.4.67 | hoch (CVSS 7.5)* | Apache 2.4.68 |
| CVE-2026-49160 (HTTP/2 Bomb, Microsoft) | Microsoft HTTP.sys und IIS | wichtig (CVSS 7.5) | Windows-Update Juni 2026 |
| CVE-2026-23918 (Double-Free, Apache) | nur Apache 2.4.66 | hoch (CVSS 8.8) | Apache 2.4.67 |
* Apache selbst stuft CVE-2026-49975 als "moderat" ein, mehrere Sicherheitsdienste vergeben 7.5. Die offizielle Bewertung in der NVD-Datenbank war Ende Juni noch nicht endgültig festgelegt.
Die ersten beiden sind dieselbe Angriffsidee in zwei Produkten. Die dritte ist ein eigener, gefährlicherer Fehler in Apache, zu dem ich gleich komme.
Wie der Angriff funktioniert
Das Trickreiche an der HTTP/2 Bomb: Sie besteht aus zwei Bausteinen, die einzeln seit zehn Jahren bekannt und für sich harmlos sind. Erst zusammen werden sie zur Waffe.
- Die Header-Bombe. HTTP/2 komprimiert Kopfzeilen mit einem Verfahren namens HPACK. Ein Sender legt einen Header einmal ab und verweist danach mit einem einzigen Byte darauf. Der Angreifer sät einen Header ein und schickt dann tausende dieser Ein-Byte-Verweise. Jeder Verweis kostet ihn ein Byte und zwingt den Server zu einer vollen Speicher-Reservierung.
- Die offene Leitung. Damit der reservierte Speicher nicht sofort wieder frei wird, hält der Angreifer die Verbindung offen. Er meldet dem Server ein Fenster von null Bytes, sodass dieser seine Antwort nie abschließen kann, und tröpfelt nur gelegentlich ein Lebenszeichen nach.
Der Kern des Problems steckt im zweiten Punkt. Eine Verstärkung von 70:1 wäre kein Drama, wenn der Server den Speicher nach der Anfrage wieder freigäbe. Gefährlich wird sie erst dadurch, dass HTTP/2 dem Client erlaubt, die Verbindung fast kostenlos offenzuhalten. Übliche Schutzgrenzen für die Header-Größe greifen nicht, weil der Speicher nicht in großen Werten steckt, sondern in der internen Buchhaltung des Servers über viele winzige Einträge.
Der gefährlichere Apache-Bug: CVE-2026-23918
Die HTTP/2 Bomb macht Server langsam, bis sie aufgeben. Eine zweite Apache-Lücke bringt sie sofort zum Absturz, und sie braucht dafür nur eine einzige Verbindung.
Der Fehler ist ein sogenannter Double-Free: Apache gibt denselben Speicherbereich zweimal frei und beschädigt dabei seine interne Verwaltung. Auslösen lässt sich das mit einem simplen Ablauf. Der Angreifer öffnet einen Datenstrom und bricht ihn sofort wieder ab, bevor der Server ihn vollständig registriert hat. Keine Anmeldung, keine spezielle Adresse, kein präparierter Header nötig.
Zwei Einschränkungen entschärfen die Lage etwas. Betroffen ist ausschließlich Apache 2.4.66. Wer diese eine Version übersprungen hat, ist außen vor. Und das klassische Prozessmodell "prefork" trifft es nicht, nur die threadbasierten Modelle "event" und "worker".
Die Entdecker von Striga.ai und ISEC.pl zeigen in ihrem Beleg, dass aus dem Absturz unter bestimmten Bedingungen sogar Codeausführung werden kann. Dieser Weg ist allerdings deutlich aufwendiger und setzt zusätzliche Lücken voraus. Realistisch bleibt für die meisten Angreifer der schnelle Absturz. Ein funktionierender Beispiel-Code kursiert bereits öffentlich.
HTTP/2 als Dauerbaustelle
Neu ist die Angriffsklasse nicht. HTTP/2 fällt seit Jahren regelmäßig mit Überlastungslücken auf, und einige davon haben Geschichte geschrieben.
- 2016, HPACK Bomb: Forscher Cory Benfield prägte den Begriff. Die Idee der Header-Bombe ist also fast ein Jahrzehnt alt.
- 2023, HTTP/2 Rapid Reset: Google, Amazon und Cloudflare legten gemeinsam eine Lücke offen, die die größten DDoS-Angriffe der Geschichte ermöglichte. Google maß dabei einen Angriff mit über 398 Millionen Anfragen pro Sekunde.
- 2024, CONTINUATION Flood: Eine ganze Serie verwandter Lücken traf Apache, Node.js und weitere Implementierungen.
Spannend ist, wie die HTTP/2 Bomb gefunden wurde. Beide Bausteine lagen seit Jahren offen in der Dokumentation, niemand hatte sie gegen diese Server kombiniert. Diesmal half eine KI: Der Forscher nutzte OpenAI Codex, das die Quelltexte durchlas und erkannte, dass sich die zwei bekannten Schwächen verbinden lassen. Genau dieser Mechanismus dürfte uns mehr solcher Funde bescheren. KI-Modelle lesen riesige Codebasen und sehen Kombinationen, die Menschen übersehen. Microsofts Juni-Patchday 2026 war mit über 200 Lücken der größte aller Zeiten, auch wegen solcher Werkzeuge.
Sind Sie betroffen? So prüfen Sie es
Bevor Sie patchen, klären Sie zwei Dinge: ob Ihr Server überhaupt HTTP/2 spricht und welche Version läuft. Drei kurze Prüfungen genügen.
- HTTP/2 aktiv?
curl -kI --http2 https://ihre-domain.dezeigt in der ersten Zeile, ob die Verbindung über HTTP/2 läuft. - Welche Version? Bei Apache
apache2ctl -voderhttpd -v, bei nginxnginx -v. - Welches Prozessmodell bei Apache?
apache2ctl -V | grep MPM. Steht dort "prefork", ist der Double-Free aus CVE-2026-23918 für Sie kein Thema.
Jetzt patchen: die sicheren Versionen
Für fast alle betroffenen Server liegen Updates bereit. Bringen Sie Ihre Installation auf mindestens diese Stände:
| Software | Sichere Version | Behebt |
|---|---|---|
| Apache httpd | 2.4.68 | HTTP/2 Bomb und Double-Free |
| nginx (HTTP/2) | 1.29.8 | HTTP/2 Bomb |
| nginx (HTTP/3) | 1.31.2 | separate HTTP/3-Lücke CVE-2026-42530 |
| Microsoft IIS | Windows-Update Juni 2026 | HTTP/2 Bomb (CVE-2026-49160) |
| Envoy | 1.35.11 / 1.36.7 / 1.37.3 / 1.38.1 | HTTP/2 Bomb |
| Cloudflare Pingora | 0.8.1 | HTTP/2 Bomb |
Ein Stolperstein: Die fertigen Pakete von Debian, Ubuntu oder Red Hat hinken den offiziellen Versionsnummern oft hinterher und liefern Korrekturen über Rückportierungen nach. Verlassen Sie sich nicht blind auf die Nummer, sondern prüfen Sie die Sicherheitshinweise Ihrer Distribution. Auch das Bundesamt für Sicherheit in der Informationstechnik warnte am 4. Juni 2026 vor den HTTP/2-Lücken und stufte das Risiko als hoch ein. In der EU verschärft der Cyber Resilience Act die Lage zusätzlich: Ab dem 11. September 2026 müssen Hersteller ausgenutzte Schwachstellen binnen 24 Stunden melden.
Wenn Sie nicht sofort patchen können
Manchmal lässt sich ein Update nicht in Minuten einspielen. Dann verschaffen Ihnen ein paar Sofortmaßnahmen Luft, ohne den Server komplett dichtzumachen.
- HTTP/2 vorübergehend abschalten. Bei Apache setzen Sie
Protocols http/1.1, bei nginx entfernen Sie dashttp2-Flag aus derlisten-Zeile oder setzenhttp2 off;. Der Geschwindigkeitsverlust durch den Rückfall auf HTTP/1.1 wiegt für die meisten Seiten leichter als ein abgestürzter Server. - Speicher pro Worker begrenzen. Über cgroups,
ulimitoder ein Container-Limit sorgen Sie dafür, dass ein vollgelaufener Prozess vom System neu gestartet wird, statt den ganzen Host in den Auslagerungsspeicher zu treiben. - Schutz davorschalten. Ein CDN oder eine Web Application Firewall fängt viele dieser Anfragen ab. Cloudflare und Imperva geben an, den Angriff automatisch zu erkennen.
- Verbindungen pro IP drosseln. Ein Limit auf gleichzeitige Verbindungen je Quelladresse nimmt dem Angriff die Wucht.
Angriff erkennen: Worauf Sie in den Logs achten
Ein laufender Angriff hinterlässt Spuren. Wer weiß, wonach er sucht, erkennt ihn früh.
- Beim Double-Free (CVE-2026-23918): Apache protokolliert abstürzende Prozesse mit dem Fehlercode
AH00052im Error-Log. Dazu kommen Meldungen wie "double free or corruption" und auffällig häufige Neustarts der Kindprozesse während HTTP/2-Verkehr. - Bei der HTTP/2 Bomb: einzelne Worker mit ungewöhnlich hohem Speicherverbrauch, Verbindungen mit dauerhaft auf null gesetztem Fenster und seltsam strukturierte Header-Ströme.
Nicht übersehen: LiteSpeed-Lücke wird bereits ausgenutzt
Während die HTTP/2-Lücken bislang nur als Beispiel-Code existieren, läuft an anderer Stelle schon ein scharfer Angriff. Wer Shared Hosting mit cPanel betreibt, sollte zusätzlich hinschauen.
Die Schwachstelle CVE-2026-54420 im LiteSpeed-Plugin für cPanel erlaubt einem Nutzer mit eingeschränktem Zugang, sich Root-Rechte auf dem Server zu verschaffen. Die US-Behörde CISA nahm die Lücke am 15. Juni 2026 in ihren Katalog aktiv ausgenutzter Schwachstellen auf. Das Update auf Plugin-Version 2.4.8 schließt sie. Wie schnell aus einer einzigen verwundbaren Komponente ein Flächenbrand wird, hat zuletzt ein Supply-Chain-Angriff über ein WordPress-Backup-Plugin gezeigt. Anders als bei der HTTP/2 Bomb ist hier nicht die Frage, ob jemand angreift, sondern nur, ob Sie schon dran sind.
Häufige Fragen
Zum Schluss die Fragen, die in Foren und Support-Tickets gerade am häufigsten auftauchen.
Wird die HTTP/2 Bomb aktiv ausgenutzt?
Bis Ende Juni 2026 gibt es keine bestätigten Angriffe in freier Wildbahn, wohl aber öffentlich verfügbaren Beispiel-Code. Keine der drei Kern-Lücken steht im CISA-Katalog aktiv ausgenutzter Schwachstellen. Das Risiko ist trotzdem real, weil fertiger Code die Hürde für Angreifer stark senkt.
Wie schalte ich HTTP/2 in Apache ab?
Tragen Sie Protocols http/1.1 in die Konfiguration des virtuellen Hosts ein und starten Sie Apache neu. Bei nginx genügt http2 off; oder das Entfernen des http2-Flags aus der listen-Direktive.
Reicht ein CDN als Schutz?
Teilweise. Hinter einem CDN ist Ihr eigentlicher Server schwerer direkt erreichbar. Ist aber das CDN selbst verwundbar, wie im Fall von Cloudflares Pingora, hilft das nicht. Cloudflare hat hier nachgebessert und erkennt den Angriff nach eigenen Angaben automatisch.
Bin ich betroffen, wenn ich nur HTTP/1.1 nutze?
Nein. Die HTTP/2 Bomb setzt eine aktive HTTP/2-Verbindung voraus. Wer ausschließlich HTTP/1.1 fährt, ist von dieser Angriffsklasse nicht betroffen. Die separate HTTP/3-Lücke in nginx wiederum betrifft nur Setups, die HTTP/3 ausdrücklich aktiviert haben.
Und wie sieht es bei Ihnen aus?
Läuft auf Ihren Servern schon die gepatchte Version, oder haben Sie HTTP/2 erst einmal abgeschaltet? Haben Sie den Fehlercode AH00052 in Ihren Logs entdeckt? Schreiben Sie es in die Kommentare. Welche Schutzmaßnahme bei Ihnen am besten funktioniert hat, hilft anderen Betreibern hier direkt weiter.
http/2 apache bomb nginx cloudflare webserver
Webung: Hier bekommen Sie PHP fähigen Webspace der mit Ökostrom betrieben wird ab bereits 2 Euro/ Monat für ihre Homepage. Zusätzlich ist eine eigene Internetadresse mit enthalten.
Neusten News in der Kategorie "Webmaster"
| • Gmail lehnt Mails ab: SPF, DKIM und DMARC einrichten Seit Ende 2025 prallen Mails ohne saubere Authentifizierung an Gmail u... |
| • PHP 8.5 Upgrade: jetzt oder doch bei 8.4 bleiben? PHP 8.1 ist tot, PHP 8.2 läuft Ende 2026 aus, ein Upgrade steht also a... |
| • KI-Crawler blocken, zur Kasse bitten oder zulassen? GPTBot, ClaudeBot und PerplexityBot überziehen Webseiten mit Anfragen.... |
| • UpdraftPlus-Lücke löst Supply-Chain-Angriff aus Erst war es nur eine Lücke im Backup-Plugin UpdraftPlus. Dann gelangte... |
| • SSL-Zertifikate 2026: Nur noch 47 Tage statt 398 Einmal im Jahr das SSL-Zertifikat erneuern? Damit ist bald Schluss. Bi... |
| • WordPress 7.0 ist da, doch Plugins bleiben das Risiko WordPress 7.0 ist da, mit KI im Core und einer gestrichenen Vorzeigefu... |
| • Cyber Resilience Act: Was ab 11. September 2026 gilt Ab dem 11. September 2026 müssen Hersteller digitaler Produkte aktiv a... |
| • GEO: So wird Ihre Website in KI-Antworten zitiert Wer bei Google ganz oben steht, taucht in ChatGPT oder Perplexity oft ... |
| • Google Spam Update Juni 2026: Das sollten Sie tun Am 24. Juni hat Google das June 2026 Spam Update ausgerollt. Ohne Blog... |
| • Token-Explosion: So ruinieren MCP-Server Ihren Coding-Workfl... MCP-Server wirken wie clevere Helfer, doch sie können Ihren KI-Co... |


Kommentar schreiben
Teilen Sie uns Ihre Meinung mit. Ihr Kommentar wird nach Pruefung veroeffentlicht.