insomnisec/detections-cve-2026-23918Reglas de detección para CVE-2026-23918 Apache http2 RCE - Crédito: stringa.ai, isec.pl
Publicado: 2026-05-04
CVSSv3: 8.8 (Alta)
Tipo: Ejecución Remota de Código / Denegación de Servicio (Corrupción de Memoria por Doble Liberación)
Componente: Apache HTTP Server mod_http2 (h2_mplx.c ruta de limpieza de flujo)
Afectado: Apache HTTP Server 2.4.66 con HTTP/2 habilitado y MPM multi-hilo
Referencias:
CVE-2026-23918 es una vulnerabilidad de corrupción de memoria por doble liberación en la implementación del protocolo HTTP/2 de Apache HTTP Server 2.4.66, que afecta solo a la ruta de limpieza de flujo del módulo mod_http2 en h2_mplx.c. Permite que un atacante remoto no autenticado provoque un bloqueo de los procesos workers de Apache (Denegación de Servicio) con una sola conexión TCP y dos tramas HTTP/2. Bajo condiciones presentes en sistemas derivados de Debian e imágenes oficiales de Apache Docker, la doble liberación puede convertirse en una Ejecución Remota de Código completa.
La explotación de DoS ha sido confirmada en entornos reales. Se han observado escaneos a gran escala en Internet dirigidos a endpoints HTTP/2. El exploit de RCE ha demostrado ser viable en entornos controlados, aunque no hay evidencia de explotación pública generalizada para RCE en este momento.
MPM prefork no se ve afectado — la vulnerabilidad requiere una configuración MPM multi-hilo (worker, event o similar). CVE-2026-23918 afecta solo a Apache HTTP Server versión 2.4.66.
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
> **Asimetría clave:** La ruta de denegación de servicio no requiere habilidad de manipulación del montón y está siendo explotada activamente. La ruta de ejecución remota de código es técnicamente exigente, pero se ha demostrado en condiciones de laboratorio y casi con toda seguridad será armada en un futuro próximo, dado que la tabla de puntuaciones tiene una dirección fija resistente a ASLR.
---
## Arquitectura de detección
> Esta sección explica por qué las herramientas de detección aquí difieren sustancialmente de un paquete típico de escalada de privilegios local.
Copy Fail (CVE-2026-31431) era una vulnerabilidad **del lado del host, posterior al acceso**. El atacante necesitaba presencia existente en el sistema. La detección residía principalmente en la capa de llamadas al sistema (auditd, Wazuh) con escaneo YARA del script PoC en disco.
CVE-2026-23918 es una vulnerabilidad **del lado de la red, previa al acceso**. El exploit llega como tramas del protocolo HTTP/2 a través de la red antes de que se ejecute cualquier código de aplicación. Esto desplaza significativamente la pila de detección:
| Capa | Copy Fail (LPE) | CVE-2026-23918 (RCE) |
|---|---|---|
| **Detección primaria** | Reglas syscall de auditd | Reglas de red de Suricata |
| **WAF (ModSecurity)** | Limitado — no puede ver el exploit | Relevante — anomalía + post-explotación |
| **Auditd** | Detección central | Detección de resultados (caídas, post-explotación) |
| **YARA** | Escanea script PoC | Escanea webshells (artefactos post-explotación) |
| **IDS de red** | No aplica | Capa de detección de primera clase |
| **Inspección TLS** | N/A | Requerida para cobertura completa de Suricata |
La regla general: para RCE a nivel de red, trabajar de afuera hacia adentro (red → WAF → host). Para escalada de privilegios local, trabajar desde el host hacia afuera.
---
## Limitaciones de la detección
> **Lea esto antes de implementar cualquier regla.**
**1. TLS termina la visibilidad de HTTP/2.**
La mayoría de las implementaciones de Apache en producción sirven HTTPS. Suricata no puede inspeccionar el contenido de las tramas HTTP/2 cifradas sin que se configure el descifrado TLS. Si su implementación de Suricata no tiene acceso a las claves de sesión TLS o a un espejo de descifrado, las reglas a nivel de red a continuación solo detectarán:
- HTTP/2 en texto claro (h2c) — poco común en producción pero presente en entornos internos
- La firma de red del comportamiento de la conexión TCP (recuento de conexiones, patrones RST en la capa TCP)
Para implementaciones HTTPS, habilite el descifrado TLS de Suricata mediante la configuración `tls-decrypt` y el registro de claves de sesión, o confíe en el WAF (ModSecurity/Coraza) y las capas basadas en host (auditd/Wazuh) en su lugar.
**2. ModSecurity no puede bloquear el desencadenante del exploit.**
La doble liberación ocurre dentro del analizador de tramas HTTP/2, antes de que se ensamble una solicitud HTTP completa y se pase a ModSecurity. El WAF ve la solicitud solo después de que se completa el análisis de la trama — momento en el cual el daño ya puede haberse producido. ModSecurity en este paquete se utiliza para detección de anomalías, limitación de velocidad y detección posterior a la explotación, no como bloqueador del desencadenante.
**3. MPM prefork no se ve afectado.**
Si su implementación de Apache utiliza `mpm_prefork_module` (monohilo), esta vulnerabilidad no aplica. El error solo se manifiesta en MPMs multihilo (`mpm_event_module` o `mpm_worker_module`). Verifique con `apachectl -V | grep MPM` antes de implementar reglas que producirían falsos positivos en servidores prefork.