insomnisec/detections-cve-2026-23918Regras de detecção para CVE-2026-23918 Apache http2 RCE - Crédito: stringa.ai, isec.pl
Publicado: 2026-05-04
CVSSv3: 8.8 (Alto)
Tipo: Execução Remota de Código / Negação de Serviço (Corrupção de Memória Double-Free)
Componente: Apache HTTP Server mod_http2 (h2_mplx.c caminho de limpeza de stream)
Afetado: Apache HTTP Server 2.4.66 com HTTP/2 ativado e MPM multi-threaded
Referências:
CVE-2026-23918 é uma vulnerabilidade de corrupção de memória double-free na implementação do protocolo HTTP/2 do Apache HTTP Server 2.4.66, afetando apenas o caminho de limpeza de stream do módulo mod_http2 em h2_mplx.c. Ela permite que um atacante remoto não autenticado derrube processos worker do Apache (Negação de Serviço) com uma única conexão TCP e dois quadros HTTP/2. Sob condições presentes em sistemas derivados do Debian e imagens oficiais do Apache Docker, o double-free pode ser moldado para Execução Remota de Código completa.
A exploração DoS foi confirmada em ambientes reais. Varreduras em larga escala na internet visando endpoints HTTP/2 foram observadas. O exploit RCE foi comprovado viável em ambientes controlados, embora não haja evidências de exploração pública generalizada para RCE neste momento.
O MPM prefork não é afetado — a vulnerabilidade requer uma configuração MPM multi-threaded (worker, event ou similar). CVE-2026-23918 afeta apenas a versão 2.4.66 do Apache HTTP Server.
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
> **Assimetria chave:** O caminho DoS não requer habilidade de manipulação de heap e está sendo ativamente explorado. O caminho RCE é tecnicamente exigente, mas foi demonstrado em condições de laboratório e quase certamente será arma no futuro próximo, dada a resistência a ASLR do endereço fixo do scoreboard.
---
## Arquitetura de Deteção
> Esta secção explica porque é que as ferramentas de deteção aqui diferem substancialmente de um pacote típico de escalada de privilégios local.
Copy Fail (CVE-2026-31431) era uma vulnerabilidade **do lado do servidor, pós-acesso**. O atacante precisava de presença existente no sistema. A deteção residia principalmente na camada de syscall (auditd, Wazuh) com análise YARA para o script PoC em disco.
CVE-2026-23918 é uma vulnerabilidade **do lado da rede, pré-acesso**. O exploit chega como frames de protocolo HTTP/2 através da rede antes de qualquer código de aplicação ser executado. Isto desloca significativamente a pilha de deteção:
| Camada | Copy Fail (LPE) | CVE-2026-23918 (RCE) |
|---|---|---|
| **Deteção primária** | Regras de syscall do auditd | Regras de rede do Suricata |
| **WAF (ModSecurity)** | Limitado — não consegue ver o exploit | Relevante — anomalia + pós-exploit |
| **Auditd** | Deteção central | Deteção de resultados (crashes, pós-exploit) |
| **YARA** | Analisa script PoC | Analisa web shells (artefatos pós-exploit) |
| **IDS de rede** | Não aplicável | Camada de deteção de primeira classe |
| **Inspeção TLS** | N/A | Necessário para cobertura total do Suricata |
A regra prática: para RCE a nível de rede, trabalhe de fora para dentro (rede → WAF → servidor). Para escalada de privilégios local, trabalhe a partir do servidor para fora.
---
## Limitações da Deteção
> **Leia isto antes de implementar quaisquer regras.**
**1. TLS termina a visibilidade HTTP/2.**
A maioria das implementações de Apache em produção serve HTTPS. O Suricata não pode inspecionar o conteúdo de frames HTTP/2 encriptados sem que a desencriptação TLS esteja configurada. Se a sua implementação do Suricata não tiver acesso às chaves de sessão TLS ou a um espelho de desencriptação, as regras de nível de rede abaixo apenas detetarão:
- HTTP/2 em texto limpo (h2c) — incomum em produção, mas presente em ambientes internos
- A assinatura de rede do comportamento da conexão TCP (contagem de conexões, padrões RST na camada TCP)
Para implementações HTTPS, ative a desencriptação TLS do Suricata através da definição `tls-decrypt` e do registo de chaves de sessão, ou confie nas camadas WAF (ModSecurity/Coraza) e baseadas no servidor (auditd/Wazuh) em alternativa.
**2. ModSecurity não pode bloquear o gatilho do exploit.**
O double-free ocorre dentro do analisador de frames HTTP/2, antes de um pedido HTTP completo ser montado e passado ao ModSecurity. O WAF vê o pedido apenas após a análise do frame estar concluída — momento em que o dano pode já ter sido feito. O ModSecurity neste pacote é utilizado para deteção de anomalias, limitação de taxa e deteção de pós-exploração, não como bloqueador do gatilho.
**3. MPM prefork não é afetado.**
Se a sua implementação do Apache utilizar `mpm_prefork_module` (single-threaded), esta vulnerabilidade não se aplica. O bug apenas se manifesta em MPMs multi-threaded (`mpm_event_module` ou `mpm_worker_module`). Verifique com `apachectl -V | grep MPM` antes de implementar regras que produziriam falsos positivos em servidores prefork.
**4. RCE requer o alocador mmap.**
O caminho RCE (não o caminho DoS) requer o alocador mmap do APR, que é o padrão em distribuições derivadas do Debian e imagens Docker oficiais do Apache. Implementações baseadas em RHEL/CentOS que utilizam jemalloc ou system malloc têm risco reduzido de RCE, mas ainda são totalmente vulneráveis a DoS.