xeloxa/cve-2026-23918-apache-h2-pocProof-of-Concept-Exploit für CVE-2026-23918 (Apache mod_http2 Double-Free). Bietet Multi-Mode-DoS (Rapid-RST, Slow-Drip) und passive RCE-/Schwachstellenerkennung für Apache 2.4.66.
Dies ist ein Proof-of-Concept-Exploit für die Double-Free-Schwachstelle in Apaches mod_http2 (CVE-2026-23918). Es ist ein übler Bug, der den Stream-Bereinigungspfad in h2_mplx.c betrifft.
Im Grunde kannst du, wenn du das Timing richtig hinbekommst, den Server dazu bringen, denselben Stream zweimal zu bereinigen, was normalerweise zu einem SIGSEGV und einem Worker-Absturz führt.
Sei nicht dumm. Verwende dies nur für autorisierte Tests. Wenn du es auf etwas einsetzt, das dir nicht gehört, bist du auf dich allein gestellt. Ich bin nicht verantwortlich für das, was du damit tust.
CVE-2026-23918 betrifft Apache 2.4.66. Es wurde Anfang dieses Monats (Mai 2026) in 2.4.67 gepatcht.
Es handelt sich um eine Race Condition in der Art und Weise, wie Apache frühe RST_STREAM-Frames verarbeitet. Wenn ein Client einen HEADERS-Frame sendet und sofort einen RST_STREAM folgen lässt, bevor der Multiplexer den Stream überhaupt registriert, versuchen zwei verschiedene Callbacks, die Bereinigung durchzuführen.
Ein Callback behandelt den Reset, der andere die Stream-Schließung. Beide rufen m_stream_cleanup() auf, das denselben Zeiger auf das Bereinigungs-Array schiebt. Wenn Apache schließlich versucht, diese Streams zu zerstören, trifft der zweite Versuch auf bereits freigegebenen Speicher.
DoS: Äußerst einfach. Eine einzige Verbindung kann Worker zum Absturz bringen. Da Apache sie neu startet, kannst du den Server mit sehr wenig Bandbreite unter konstantem Druck halten. Das demonstriert dieser PoC – und er wurde auf Apache 2.4.66 getestet und als funktionierend bestätigt.
RCE: Theoretisch möglich, aber für die meisten Angreifer nicht praktikabel. Es erfordert:
mmap, Standard auf Debian/Ubuntu/Docker)Es existiert kein öffentlicher RCE-Exploit, und dessen Entwicklung ist ein nicht-trivialer technischer Aufwand. Die reale Auswirkung für die meisten Organisationen ist zuverlässiger DoS, nicht RCE.
Du benötigst Python 3.9+ und die Bibliothek h2.
git clone https://github.com/xeloxa/CVE-2026-23918-Apache-H2-PoC.git
cd CVE-2026-23918-Apache-H2-PoC
pip install -r requirements.txt
Ein lokales Labor zum Absturz bringen:
# Aggressiver DoS
python3 cve-2026-23918.py --target 127.0.0.1 --port 8443 --mode dos
Prüfen, ob ein Ziel möglicherweise verwundbar ist:
# Dies ist passiv, es prüft nur Header und H2-Unterstützung
python3 cve-2026-23918.py --target example.com --mode rce-detect
Anhaltender Druck:
# Geringe Bandbreite, lange Dauer
python3 cve-2026-23918.py --target 10.0.0.50 --mode slow-drip -d 60
Wenn du 2.4.66 ausführst, musst du auf 2.4.67 wechseln.
Wenn du jetzt nicht aktualisieren kannst, kannst du HTTP/2 deaktivieren, indem du Protocols http/1.1 zu deiner Konfiguration hinzufügst (oder einfach h2 aus der Liste entfernst). Das ist nicht ideal für die Leistung, stoppt aber den Absturz.
Ich habe dies auf einigen verschiedenen Debian- und Ubuntu-Builds getestet. Der DoS ist sehr zuverlässig. RCE ist deutlich "heikler" und ich würde in einem realen Szenario nicht darauf zählen, es sei denn, das Ziel hat einen sehr vorhersehbaren Heap-Zustand.