insomnisec/detections-cve-2026-23918Règles de détection pour CVE-2026-23918 Apache http2 RCE - Credit: stringa.ai, isec.pl
Publié : 2026-05-04
CVSSv3 : 8.8 (Élevé)
Type : Exécution de code à distance / Déni de service (Double-Free Memory Corruption)
Composant : Serveur HTTP Apache mod_http2 (h2_mplx.c chemin de nettoyage des flux)
Affecté : Serveur HTTP Apache 2.4.66 avec HTTP/2 activé et MPM multi-threadé
Références :
CVE-2026-23918 est une vulnérabilité de corruption mémoire de type double-free dans l'implémentation du protocole HTTP/2 du serveur HTTP Apache 2.4.66, affectant uniquement le chemin de nettoyage des flux du module mod_http2 dans h2_mplx.c. Elle permet à un attaquant distant non authentifié de faire planter les processus workers d'Apache (déni de service) avec une seule connexion TCP et deux trames HTTP/2. Dans des conditions présentes sur les systèmes dérivés de Debian et les images Docker officielles d'Apache, le double-free peut être modelé pour une exécution de code à distance complète.
L'exploitation DoS a été confirmée dans la nature. Des scans Internet à grande échelle ciblant les points de terminaison HTTP/2 ont été observés. L'exploit RCE s'est avéré viable dans des environnements contrôlés, bien qu'il n'y ait aucune preuve d'exploitation publique généralisée pour RCE à l'heure actuelle.
Le MPM prefork n'est pas affecté — la vulnérabilité nécessite une configuration MPM multi-threadé (worker, event ou similaire). CVE-2026-23918 n'affecte que la version 2.4.66 du serveur HTTP Apache.
Attacker opens HTTP/2 connection to Apache 2.4.66 (mod_http2 loaded, multi-threaded MPM) └─ Sends HTTP/2 HEADERS frame on stream N (opens the stream) └─ Immediately sends RST_STREAM on stream N (non-zero error code) └─ Sent BEFORE the multiplexer has registered the stream
Two nghttp2 callbacks fire in sequence: ├─ on_frame_recv_cb (RST received) → calls h2_mplx_c1_client_rst → m_stream_cleanup └─ on_stream_close_cb (stream closed) → calls h2_mplx_c1_client_rst → m_stream_cleanup
Result: same h2_stream pointer pushed onto spurge[] cleanup array TWICE
c1_purge_streams() iterates spurge[] and calls h2_stream_destroy() on each entry: ├─ First call: valid — frees the stream └─ Second call: DOUBLE-FREE — operates on already-freed memory → heap corruption
DoS path (trivial, in the wild): └─ Heap corruption → SIGABRT in worker process → worker dies → service disruption
RCE path (requires mmap allocator — default on Debian/Ubuntu and official Docker): └─ Attacker places fake h2_stream struct at freed virtual address via mmap reuse └─ Points pool cleanup function pointer to system() └─ Uses Apache scoreboard shared memory (fixed address, ASLR-resistant) as payload container └─ c1_purge_streams() executes system() with attacker-controlled argument → RCE
> **Asymétrie clé :** La voie DoS ne nécessite aucune compétence de manipulation du tas et est activement exploitée. La voie RCE est techniquement exigeante mais a été démontrée en laboratoire et sera presque certainement transformée en arme dans un avenir proche compte tenu de l'adresse fixe résistante à l'ASLR du scoreboard.
---
## Architecture de détection
> Cette section explique pourquoi les outils de détection ici diffèrent substantiellement d'un package typique d'escalade de privilèges locaux.
Copy Fail (CVE-2026-31431) était une vulnérabilité **côté hôte, post-accès**. L'attaquant devait déjà être présent sur le système. La détection résidait principalement au niveau des appels système (auditd, Wazuh) avec un scan YARA pour le script PoC sur le disque.
CVE-2026-23918 est une vulnérabilité **côté réseau, pré-accès**. L'exploit arrive sous forme de trames de protocole HTTP/2 sur le réseau avant que le code applicatif ne s'exécute. Cela modifie considérablement la pile de détection :
| Couche | Copy Fail (LPE) | CVE-2026-23918 (RCE) |
|---|---|---|
| **Détection principale** | Règles d'appels système auditd | Règles réseau Suricata |
| **WAF (ModSecurity)** | Limité — ne peut pas voir l'exploit | Pertinent — anomalie + post-exploitation |
| **Auditd** | Détection de base | Détection des conséquences (plantages, post-exploitation) |
| **YARA** | Scanne le script PoC | Scanne les web shells (artefacts post-exploitation) |
| **IDS réseau** | Non applicable | Couche de détection de premier ordre |
| **Inspection TLS** | N/A | Requise pour une couverture complète de Suricata |
La règle empirique : pour une RCE au niveau réseau, travailler de l'extérieur vers l'intérieur (réseau → WAF → hôte). Pour une escalade de privilèges locale, travailler de l'hôte vers l'extérieur.
---
## Limites de la détection
> **Lisez ceci avant de déployer une règle quelconque.**
**1. TLS interrompt la visibilité HTTP/2.**
La plupart des déploiements Apache en production servent du HTTPS. Suricata ne peut pas inspecter le contenu des trames HTTP/2 chiffrées sans que le déchiffrement TLS ne soit configuré. Si votre déploiement Suricata n'a pas accès aux clés de session TLS ou à un miroir de déchiffrement, les règles réseau ci-dessous ne détecteront que :
- HTTP/2 en clair (h2c) — rare en production mais présent dans les environnements internes
- La signature réseau du comportement de la connexion TCP (nombre de connexions, motifs RST au niveau TCP)
Pour les déploiements HTTPS, activez le déchiffrement TLS de Suricata via le paramètre `tls-decrypt` et la journalisation des clés de session, ou reposez-vous plutôt sur les couches WAF (ModSecurity/Coraza) et hôte (auditd/Wazuh).
**2. ModSecurity ne peut pas bloquer le déclencheur de l'exploit.**
La double libération se produit à l'intérieur du parseur de trames HTTP/2, avant qu'une requête HTTP complète ne soit assemblée et transmise à ModSecurity. Le WAF ne voit la requête qu'après la fin de l'analyse de la trame — moment où les dégâts peuvent déjà être faits. ModSecurity dans ce package est utilisé pour la détection d'anomalies, la limitation de débit et la détection post-exploitation, pas comme bloqueur du déclencheur.
**3. MPM prefork n'est pas affecté.**
Si votre déploiement Apache utilise `mpm_prefork_module` (monothreadé), cette vulnérabilité ne s'applique pas. Le bogue ne se manifeste que dans les MPM multithreadés (`mpm_event_module` ou `mpm_worker_module`). Vérifiez avec `apachectl -V | grep MPM` avant de déployer des règles qui produiraient des faux positifs sur les serveurs prefork.