xeloxa/cve-2026-23918-apache-h2-pocPreuve de concept d'exploitation pour CVE-2026-23918 (double libération dans Apache mod_http2). Dispose d'un DoS multi-mode (Rapid-RST, Slow-Drip) et d'une détection passive de RCE/vulnérabilité pour Apache 2.4.66.
Il s'agit d'un exploit de preuve de concept pour la vulnérabilité de double libération dans mod_http2 d'Apache (CVE-2026-23918). C'est un bug vicieux qui touche le chemin de nettoyage des flux dans h2_mplx.c.
En gros, si vous chronométrez bien, vous pouvez amener le serveur à tenter de nettoyer deux fois le même flux, ce qui mène généralement à un SIGSEGV et à un crash du worker.
Ne soyez pas stupide. Utilisez ceci uniquement pour des tests autorisés. Si vous l'utilisez sur quelque chose qui ne vous appartient pas, vous êtes seul responsable. Je ne suis pas responsable de ce que vous en faites.
CVE-2026-23918 affecte Apache 2.4.66. Le correctif a été publié dans la version 2.4.67 plus tôt ce mois-ci (mai 2026).
C'est une condition de course dans la façon dont Apache gère les trames RST_STREAM précoces. Si un client envoie une trame HEADERS et la fait immédiatement suivre d'un RST_STREAM avant même que le multiplexeur n'enregistre le flux, deux callbacks différents tentent de faire le nettoyage.
Un callback gère la réinitialisation, l'autre gère la fermeture du flux. Les deux appellent m_stream_cleanup(), qui pousse le même pointeur dans le tableau de nettoyage. Lorsqu'Apache tente finalement de détruire ces flux, la seconde tentative accède à une mémoire déjà libérée.
DoS : Extrêmement facile. Une seule connexion peut faire crasher des workers. Comme Apache les relance, vous pouvez maintenir le serveur sous pression constante avec très peu de bande passante. C'est ce que démontre ce PoC — et il a été testé et confirmé fonctionnel sur Apache 2.4.66.
RCE : Théoriquement possible mais pas pratique pour la plupart des attaquants. Cela nécessite :
mmap, par défaut sur Debian/Ubuntu/Docker)Aucun exploit RCE public n'existe, et en construire un est un effort d'ingénierie non trivial. L'impact réel pour la plupart des organisations est un DoS fiable, pas une RCE.
Vous aurez besoin de Python 3.9+ et de la bibliothèque 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
Faire crasher un laboratoire local :
# DoS agressif
python3 cve-2026-23918.py --target 127.0.0.1 --port 8443 --mode dos
Vérifier si une cible pourrait être vulnérable :
# Ceci est passif, cela vérifie simplement les en-têtes et le support H2
python3 cve-2026-23918.py --target example.com --mode rce-detect
Pression soutenue :
# Faible bande passante, longue durée
python3 cve-2026-23918.py --target 10.0.0.50 --mode slow-drip -d 60
Si vous utilisez la version 2.4.66, vous devez passer à la 2.4.67.
Si vous ne pouvez pas mettre à jour immédiatement, vous pouvez désactiver HTTP/2 en ajoutant Protocols http/1.1 à votre configuration (ou simplement retirer h2 de la liste). Ce n'est pas idéal pour les performances, mais cela arrête le crash.
J'ai testé ceci sur plusieurs builds Debian et Ubuntu. Le DoS est très fiable. La RCE est beaucoup plus « capricieuse » et je ne compterais pas dessus dans un scénario réel, sauf si la cible présente un état du tas très prévisible.