Es war einer dieser Bugs, die mit einem winzigen Detail beginnen und in einer maximalen Konsequenz enden. Ein HTTP/2-Client schickt einen HEADERS-Frame, hängt direkt ein RST_STREAM mit Fehlercode an – noch bevor der Multiplexer den Stream überhaupt registriert hat. Was im Protokoll-Diagramm wie ein nebensächlicher Sonderfall aussieht, ist seit dem 4. Mai 2026 die gefährlichste Schwachstelle, die in den letzten Monaten in einem Open-Source-Standardbaustein des Internets auftauchte: CVE-2026-23918, ein Double-Free im Apache-Modul mod_http2, CVSS-Score 8,8.

Apache HTTP Server gehört im deutschen Mittelstand zur stillen Infrastruktur, die niemand mehr beachtet, weil sie seit Jahren stabil läuft. Genau diese Selbstverständlichkeit wird jetzt zum Problem. Denn die DoS-Variante des Bugs ist nicht nur trivial reproduzierbar – sie wird seit der Veröffentlichung der ersten Proof-of-Concepts aktiv in freier Wildbahn ausgenutzt. Wer 2.4.66 produktiv betreibt und auf 2.4.67 verzichtet, hat keinen Wartungsrückstand mehr, sondern ein akutes Sicherheitsproblem.

Was bei CVE-2026-23918 wirklich passiert

Der Fehler steckt im Stream-Cleanup-Pfad von h2_mplx.c innerhalb von mod_http2. Wenn ein Client unmittelbar nach einem HEADERS-Frame einen RST_STREAM mit Non-Zero-Errorcode auf derselben Stream-ID schickt, feuern in nghttp2 zwei Callbacks hintereinander: on_frame_recv_cb für den Reset und on_stream_close_cb für den anschliessenden Close. Beide rufen über den gleichen Pfad h2_mplx_c1_client_rst → m_stream_cleanup auf und schieben denselben h2_stream-Pointer zweimal auf das spurge-Cleanup-Array.

Wenn c1_purge_streams später durch dieses Array iteriert, ruft es h2_stream_destroy auf einen Pointer auf, der bereits freigegeben wurde. Klassischer Double-Free, mit allen Konsequenzen, die sich Sicherheitsforscher seit zwei Jahrzehnten an Memory-Corruption-Bugs ausmalen können.

Die beiden Eskalationspfade unterscheiden sich erheblich in der praktischen Ausnutzbarkeit:

Pfad 1 – Denial-of-Service (trivial)

Ein einziger Request reicht, um einen Apache-Worker zu zerlegen. Wiederholt ausgeführt bringt das jede Standard-Deployment mit einem Multi-Threaded MPM (worker, event) zum Absturz. Public-PoCs auf GitHub – unter anderem xeloxa/CVE-2026-23918-Apache-H2-PoC und rhasan-com/CVE-2026-23918 – bieten Modi wie Rapid-RST und Slow-Drip zum schmerzfreien Reproduzieren. Das ist die Variante, die aktuell in der Wildbahn auftritt: grossflächige Scans, gezielte Down-Attacks auf öffentliche Webfrontends, Erpressungsversuche im Stil "Pay or we keep crashing your reverse proxy".

Pfad 2 – Remote Code Execution (anspruchsvoller, aber praktikabel)

Die RCE-Kette ist deutlich komplexer und setzt einen APR-Build mit dem mmap-Allokator voraus – Standard auf Debian-Derivaten und in den offiziellen Apache-Builds. Die Angreifer platzieren über mmap-Reuse eine gefälschte h2_stream-Struktur an der freigegebenen Adresse, biegen den Pool-Cleanup-Pointer auf system() um und legen die Kommandozeile im Apache-Scoreboard ab. Das Scoreboard sitzt an einer festen Adresse über die gesamte Server-Lifetime, sogar mit ASLR – und macht den RCE-Pfad damit überhaupt erst stabil. Eine grossflächige Massen-Exploitation für RCE ist Stand 23. Mai noch nicht beobachtet worden, das Können ist jedoch öffentlich.

Wer ist betroffen – und wer nicht

Der Bug existiert ausschliesslich in Apache HTTP Server 2.4.66. Frühere Versionen sind nicht betroffen, weil die fehlerhafte Code-Pfade-Refaktorierung in 2.4.66 erstmals enthalten ist. Wichtig für das Inventar:

  • Multi-Threaded MPM erforderlich: Wer noch auf prefork setzt – im Mittelstand häufig bei klassischen PHP-Stacks der Fall – ist von dieser konkreten Schwachstelle nicht betroffen. Eine Entwarnung ist das nicht: prefork hat eigene Performance- und Sicherheits-Nachteile.
  • mod_http2 aktiv: Wenn Sie in der Apache-Konfiguration Protocols h2 h2c http/1.1 stehen haben, sind Sie potenziell verwundbar.
  • Vorgelagerte Reverse Proxies entschärfen den Bug nicht automatisch: Wenn der Apache hinter einem NGINX-Ingress oder einem HAProxy steht und HTTP/2 zum Apache durchgereicht wird, bleibt die Verwundbarkeit. Nur eine Konfiguration, die ausschliesslich HTTP/1.1 zum Apache spricht, wirkt als Mitigation.

Sofortmassnahmen für den Mittelstand

Wir empfehlen Ihren IT-Teams ein klar gestaffeltes Vorgehen für die nächsten 72 Stunden:

1. Inventarisieren, was wirklich läuft

Ein schneller Check über die installierten Pakete ist der Anfang, aber nicht das Ende. Versionen können durch Distributions-Backports anders aussehen, als der Banner verspricht. Verlässlich ist nur ein Pull der tatsächlich geladenen Modul-Version:

httpd -V
httpd -M | grep http2
apachectl -t -D DUMP_MODULES | grep http2

Plus die Frage: läuft der Apache als worker, event oder prefork? Das entscheidet, ob die DoS-Variante trifft.

2. Patchen auf 2.4.67

Der einzige vollständige Fix ist das Upgrade auf Apache HTTP Server 2.4.67 oder neuer. Der Patch im Cleanup-Pfad von h2_mplx.c stellt sicher, dass derselbe h2_stream-Pointer nur einmal in das spurge-Array gelangt – egal wie viele Callbacks während eines Early-Stream-Resets feuern. Wer Apache aus Distributionspaketen zieht, sollte gezielt prüfen, ob der Hotfix bereits zurückportiert wurde – Red Hat, Debian und Ubuntu hatten Stand 22. Mai bereits Sicherheitsupdates ausgerollt.

3. Mitigation, wenn der Patch nicht sofort möglich ist

Falls Wartungsfenster, Change-Approval oder abhängige Anwendungen einen sofortigen Patch verhindern, ist das HTTP/2-Protokoll temporär abzuschalten. Die einfachste und vollständige Mitigation lautet:

Protocols http/1.1

Damit fällt der gesamte mod_http2-Codepfad raus. Performance-Einbussen für moderne Clients sind hinnehmbar, das Risiko ist eliminiert. Wer dazwischenstufen will, kann selektiv pro VirtualHost den HTTP/2-Support deaktivieren und so geschäftskritische APIs zuerst absichern.

4. Logs auf Indicators of Attack prüfen

Die DoS-Variante hinterlässt charakteristische Spuren. Suchen Sie im Access-Log und im Errorlog gezielt nach:

  • Sehr kurzen Verbindungen mit HTTP/2-Stream-IDs, die unmittelbar nach Eröffnung mit Error-Code 0x8 (CANCEL) oder 0x1 (PROTOCOL_ERROR) geschlossen werden.
  • Häufungen von Worker-Crashes (child pid 12345 exit signal Segmentation fault) ohne nachvollziehbaren Anwendungsfehler.
  • Auffälligen Traffic-Mustern aus IP-Ranges, die zuvor nicht prominent in Ihren Logs auftauchten.

5. Reverse-Proxy- und WAF-Regeln ergänzen

Wer einen vorgelagerten Layer hat, kann den spezifischen Angriffsvektor auf der Edge filtern. Eine WAF-Regel, die RST_STREAM-Frames innerhalb eines kritischen Zeitfensters nach einem HEADERS-Frame auf derselben Stream-ID erkennt, sperrt die Triggerbedingung ab. Kommerzielle WAFs (Cloudflare, AWS, F5) haben Stand 23. Mai bereits passende Signaturen veröffentlicht.

Was die Geschichte über Open-Source-Verantwortung verrät

Die Schwachstelle wurde im Dezember 2025 durch Bartlomiej Dmitruk (striga.ai) und Stanislaw Strzalkowski (isec.pl) an das Apache Security Team gemeldet. Der Public-Patch ging fünf Monate später am 4. Mai 2026 raus. In dieser Zeitspanne lief der Wettlauf zwischen verantwortungsvoller Offenlegung, Patch-Erarbeitung und der unvermeidlichen Tatsache, dass jeder Diff am Open-Source-Repository eine implizite Roadmap für Angreifer ist. Innerhalb von 48 Stunden nach Release der 2.4.67 lagen die ersten DoS-PoCs auf GitHub. Wer auf Auto-Updates verzichtet und Patch-Latenz von Wochen toleriert, verliert dieses Rennen mit absoluter Sicherheit.

Die unbequeme Wahrheit über Webserver-Hygiene im Mittelstand

Apache HTTP Server gilt in vielen Unternehmen als "läuft halt"-Infrastruktur. Aktualisiert wird, wenn die Distribution ein Major-Release nachzieht – also alle paar Jahre. Patch-Frequenz auf Modul-Ebene? Selten dokumentiert. Inventar der vor- und nachgelagerten Module? Häufig nicht aktuell. CVE-2026-23918 zeigt erneut, dass Webserver-Stacks zur produktionskritischen Software-Schicht gehören, die in den regulären Informationssicherheits-Prozess integriert werden muss – inklusive Asset Inventory, Patch-Latenz-Monitoring und einem dokumentierten Mitigation-Spielbuch für Edge-Komponenten.

Wir bei pleXtec begleiten Mittelständler regelmässig dabei, ihre Webserver- und Reverse-Proxy-Landschaft aus der "läuft halt"-Ecke in eine bewusste, gemanagte Architektur zu überführen. Dazu gehört auch eine realistische Bewertung, welche Komponenten überhaupt einen aktiv gepflegten Lifecycle haben und welche im stillen Wartungsschacht hängen – exakt wie es jetzt bei zigtausend Apache-Installationen sichtbar wird.

Was wir Ihnen empfehlen

Wenn Sie sich am Wochenende vom 23./24. Mai unsicher sind, ob Ihr Stack betroffen ist, beginnen Sie mit den drei Fragen:

  1. Welche Apache-Version läuft auf welchen öffentlich erreichbaren Hosts?
  2. Ist mod_http2 aktiviert und mit welchem MPM?
  3. Wer im Team hat in den nächsten 24 Stunden Zugriffs- und Change-Rechte, um zu patchen oder das Protokoll zu degradieren?

Wenn Sie auf eine dieser Fragen keine sofortige Antwort haben, ist das Inventar Ihre erste Baustelle, nicht der Patch. Sprechen Sie uns an, wenn Sie eine externe Bewertung Ihrer Webserver- und Edge-Layer-Architektur möchten – wir helfen schnell und pragmatisch. Mehr Informationen finden Sie in unserem Leistungsangebot oder direkt über das Kontaktformular.

Stand: 23. Mai 2026. Wir aktualisieren diesen Artikel, sobald sich die Bedrohungslage – insbesondere bei der RCE-Variante – relevant verändert.