Apache hat die CVE-2026-23918, eine kritische Schwachstelle in der HTTP/2-Verarbeitung des Apache HTTP Servers, gepatcht, die Apache als „double free und mögliches RCE“ beschreibt. Das Problem betrifft Apache HTTP Server 2.4.66 und wurde in 2.4.67 behoben, das am 4. Mai 2026 veröffentlicht wurde.
Die Schwachstelle CVE-2026-23918 ist von Bedeutung, weil sie aus der Ferne und ohne Authentifizierung ausgenutzt werden kann. Öffentliche Berichte besagen, dass der Fehler eine Denial-of-Service-Bedingung verursachen kann und unter bestimmten Bedingungen auch einen Weg zur Remote-Code-Ausführung öffnen könnte, was es zu einem der schwerwiegendsten in Apaches letztem Sicherheitsupdate behandelten Probleme macht.
Apache schreibt Bartlomiej Dmitruk von striga.ai und Stanislaw Strzalkowski von isec.pl die Meldung des Fehlers zu. Apaches eigene Schwachstellen-Seite zeigt, dass sie am 10. Dezember 2025 an das Sicherheitsteam gemeldet, am 11. Dezember 2025 im Quellcode behoben und Monate später in der 2.4.67-Version an die Benutzer ausgeliefert wurde.
Analyse der CVE-2026-23918
Laut Apache und von The Hacker News zitiertem Forscherkommentar ist der Fehler ein double-free in mod_http2, speziell im Stream-Cleanup-Pfad. Er kann ausgelöst werden, wenn ein Client einen HTTP/2 HEADERS-Frame sendet und dann sofort RST_STREAM mit einem nicht-null Fehlercode sendet, bevor der Stream vollständig vom Multiplexer registriert wird.
Diese Sequenz kann zwei Callbacks dazu bringen, so zu laufen, dass dasselbe Stream-Objekt zweimal in das Cleanup-Array eingefügt wird. Wenn Apache später die Stream-Einträge zerstört, wird bereits freier Speicher erneut freigegeben. In praktischen Begriffen ist die Schwachstelle in CVE-2026-23918 ein Speicherverwaltungsfehler, der Worker-Prozesse zum Absturz bringen kann und der, in der richtigen Umgebung, zur Code-Ausführung geformt werden kann.
Der Denial-of-Service-Weg scheint das einfachste Ergebnis zu sein. Die Forscher teilten The Hacker News mit, dass eine TCP-Verbindung und zwei HTTP/2-Frames ausreichen, um einen Worker in Standardbereitstellungen zum Absturz zu bringen, die mod_http2 mit einem Multithread-MPM verwenden. Sie bemerkten auch, dass MPM prefork nicht betroffen ist, während der mögliche RCE-Pfad von einer APR-Konfiguration abhängt, die den mmap-Allocator verwendet, der angeblich standardmäßig auf Debian-abgeleiteten Systemen und im offiziellen httpd-Docker-Image ist.
Hinsichtlich der Ausnutzungsreife sagen öffentliche Berichte, dass die Forscher einen funktionierenden Proof-of-Concept für CVE-2026-23918 für x86_64 unter Laborkonditionen aufgebaut haben. Sie sagten auch, dass eine praktische Ausnutzung immer noch unterstützende Bedingungen wie ein Informationsleck und eine günstige Speicherwiederverwendung benötigt, sodass die Code-Ausführung anspruchsvoller ist als eine einfache Dienstunterbrechung.
In diesem Stadium weisen öffentliche Details für CVE-2026-23918 viel deutlicher auf Prozessabstürze und Arbeiterinstabilität hin als auf weitgehend reproduzierbare RCE im Feld. Es gibt auch keine von Anbietern veröffentlichten CVE-2026-23918-iocs, sodass Verteidiger sich auf Versionsexposition, unerwartete Arbeiterabstürze und verdächtige HTTP/2-Reset-Muster konzentrieren sollten, anstatt auf einen stabilen Signatursatz.
Abmilderung von CVE-2026-23918
Die Kernlösung besteht darin, Apache HTTP Server von Version 2.4.66 auf 2.4.67 zu aktualisieren. Apaches Sicherheitshinweis empfiehlt ausdrücklich, zur gepatchten Version zu wechseln, und SecurityWeek weist darauf hin, dass die Veröffentlichung 11 Schwachstellen behebt, einschließlich dieses kritischen HTTP/2-Problems.
Für eine sofortige Triage sollten Verteidiger internetnahe Systeme identifizieren, auf denen mod_http2 aktiviert ist und in denen Thread-MPMs verwendet werden. Das ist der praktischste Weg, um eine CVE-2026-23918-Exposition zu erkennen, da der Angriff auf HTTP/2-Anfragenverarbeitung basiert, nicht auf einem abgelegten Malwareresp artefakt oder traditionellem Post-Exploitation-Beacon.
Wenn die Notfall-Patches verzögert werden, kann die Reduzierung der HTTP/2-Belastung helfen, die Angriffsfläche zu verkleinern, bis Updates angewendet werden. Die öffentlich beschriebene CVE-2026-23918-Nutzlast ist keine herkömmliche Datei oder Binärdatei, sondern eine präparierte Sequenz von HTTP/2-Frames, die den fehlerhaften Cleanup-Pfad erzwingt, sodass netzwerknahe Apache-Instanzen zuerst priorisiert werden sollten.
Aus Risikoperspektive betrifft CVE-2026-23918 Organisationen, die sich auf Apache HTTP Server 2.4.66 für öffentliche Web-Workloads verlassen, insbesondere dort, wo HTTP/2 standardmäßig aktiviert oder weit verbreitet aus Leistungsgründen eingesetzt wird. Dazu gehören Standard-Linux-basierte Webserver sowie containerisierte Bereitstellungen unter Verwendung des offiziellen Apache-Images.
FAQ
Was ist CVE-2026-23918 und wie funktioniert es?
Es ist ein kritischer double-free Fehler in der HTTP/2-Verarbeitung des Apache HTTP Servers. Eine speziell getimte Sequenz von HTTP/2-Frames kann dasselbe Stream-Objekt zweimal in das Cleanup-Pfad einfügen, was zu Abstürzen der Worker und möglicherweise unter günstigen Bedingungen zur Remote-Code-Ausführung führt.
Wann wurde CVE-2026-23918 zuerst entdeckt?
Apaches Schwachstellen-Seite besagt, dass das Problem am 10. Dezember 2025 an das Sicherheitsteam gemeldet wurde. Die Behebung landete am 11. Dezember 2025 im Quellcode und das gepatchte 2.4.67-Release wurde am 4. Mai 2026 veröffentlicht.
Was ist die Auswirkung von CVE-2026-23918 auf Systeme?
Die unmittelbarste Auswirkung ist ein Dienstverweigerung durch abgestürzte Apache-Worker. Öffentliche Berichte sagen auch, dass der Fehler möglicherweise Remote-Code-Ausführung ermöglicht, obwohl dieser Weg komplexer und umgebungsabhängiger erscheint als das Absturzszenario.
Kann CVE-2026-23918 mich auch 2026 noch betreffen?
Ja. Systeme können auch 2026 noch gefährdet sein, wenn sie Apache HTTP Server 2.4.66 mit aktiviertem mod_http2 betreiben und noch nicht auf 2.4.67 aktualisiert wurden. Das Risiko ist besonders relevant für Bereitstellungen, die Thread-MPMs verwenden.
Wie kann ich mich vor CVE-2026-23918 schützen?
Aktualisieren Sie so schnell wie möglich auf Apache HTTP Server 2.4.67, identifizieren Sie exponierte HTTP/2-fähige Bereitstellungen und priorisieren Sie serverseitig erreichbare Server für die Sanierung. Wo das Patchen nicht sofort erfolgen kann, kann eine Reduzierung der HTTP/2-Exposition dazu beitragen, das kurzfristige Risiko zu verringern.