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.

1. 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.
2. 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.de zeigt in der ersten Zeile, ob die Verbindung über HTTP/2 läuft.
• Welche Version? Bei Apache apache2ctl -v oder httpd -v, bei nginx nginx -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 das http2-Flag aus der listen-Zeile oder setzen http2 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, ulimit oder 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 AH00052 im 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.

Ähnlich brisant und ebenfalls bereits angegriffen ist die aktiv ausgenutzte LiteSpeed-cPanel-Lücke.

Solche Server-Lücken sind genau der Grund für die neuen NIS2-Sicherheitspflichten, die seit Ende 2025 gelten.

Fällt der Server aus, zählt vor allem, wie schnell sich die Seite zurückholen lässt. Wie Sie ein getestetes Backup aufsetzen und prüfen, zeigt dieser Beitrag.

Setzen Sie Apache oder nginx ein und haben Sie die HTTP/2 Bomb schon geprüft? Jetzt Ihre Meinung teilen

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"

• Strukturierte Daten 2026: mit Schema zu Rich Snippets Sterne, Preise und Bilder direkt im Google-Ergebnis bringen mehr Klick...

• Impressum und Datenschutz 2026: rechtssichere Website Ein fehlerhaftes Impressum oder eine lückenhafte Datenschutzerklärung ...

• WordPress schneller machen 2026: Caching und Tuning WordPress erzeugt jede Seite bei jedem Aufruf neu, das kostet Tempo un...

• Bilder fürs Web optimieren 2026: schneller mit AVIF Bilder sind auf den meisten Seiten der größte Bremsklotz für die Ladez...

• WordPress absichern 2026: Schutz vor Hackerangriffen WordPress ist das beliebteste Ziel automatisierter Angriffe, neue Lück...

• Website umziehen 2026: ohne Ausfall und Ranking-Verlust Ein Hosting-Wechsel kann die Seite tagelang lahmlegen oder das Google-...

• E-Mail-Zustellbarkeit 2026: Raus aus dem Spam-Ordner Bestellbestätigungen, Newsletter und Kontaktmails landen plötzlich im ...

• Website-Backups 2026: Die Strategie gegen Datenverlust Ein Hack, ein fehlgeschlagenes Update, ein Serverausfall, und die Seit...

• Cookie-Banner 2026: Was jetzt wirklich Pflicht ist Cookie-Banner verschwinden 2026 doch nicht. Welche Regeln gelten, welc...

• Core Web Vitals 2026: Was beim Ranking wirklich zählt Mehr als vier von zehn Websites fallen bei Googles Core Web Vitals dur...