Falha de duplo free no mod_http2 do Apache HTTP Server 2.4.66 pode derrubar workers sem autenticação e, em condições específicas de alocador e vazamento de informação, abrir caminho para execução remota de código.
| Componente | Apache HTTP Server 2.4.66 com mod_http2, no caminho de limpeza de streams em h2_mplx.c. |
| Vetor | Uma conexão TCP envia um frame HTTP/2 HEADERS seguido imediatamente por RST_STREAM com código de erro diferente de zero no mesmo stream, antes do registro pelo multiplexador. |
| Impacto | Negação de serviço por falha de worker sem autenticação; possível execução remota de código quando há APR com alocador mmap, reutilização de endereço liberado e vazamento de endereços necessários. |
| Prioridade | Atualizar o Apache HTTP Server para 2.4.67 e revisar exposição de HTTP/2 em implantações com MPM multi-threaded. |
| Versões | A falha afeta Apache HTTP Server 2.4.66 e foi corrigida na versão 2.4.67. |
| Artefatos | CVE-2026-23918, mod_http2, h2_mplx.c, h2_mplx_c1_client_rst, m_stream_cleanup, c1_purge_streams, h2_stream_destroy, apr_pool_destroy. |
| Limites | MPM prefork não é afetado; o caminho de RCE exige condições adicionais, incluindo vazamento de informação para resolver system() e offsets do scoreboard. |
A vulnerabilidade CVE-2026-23918 é uma falha de gerenciamento de memória no tratamento de HTTP/2 do Apache HTTP Server 2.4.66. O defeito está associado ao módulo mod_http2 e ao caminho de limpeza de streams em h2_mplx.c, onde uma sequência específica de frames consegue fazer o mesmo ponteiro h2_stream ser inserido duas vezes na estrutura usada para purga. Quando a rotina posterior percorre essa lista de limpeza, a mesma área de memória é destruída mais de uma vez. O resultado imediato é uma condição de duplo free, com queda do worker que processou a conexão. Em ambientes com HTTP/2 habilitado, a exploração para negação de serviço não exige autenticação, cabeçalhos especiais, rota específica nem corpo de requisição complexo.
O impacto prático depende do modelo de processamento e do alocador em uso. Em implantações com mod_http2 e MPM multi-threaded, a negação de serviço é direta: um cliente remoto estabelece uma conexão TCP e envia dois frames em uma ordem precisa para atingir o caminho vulnerável. O Apache pode recriar o worker, mas as requisições que estavam naquele processo ou thread de execução são interrompidas, e o padrão pode ser repetido para manter perda de disponibilidade. A possibilidade de execução remota de código é mais restrita, mas tecnicamente relevante: ela depende de um APR com alocador baseado em mmap, condição apontada como padrão em sistemas derivados de Debian e na imagem oficial httpd para Docker, além de vazamentos de informação para calcular endereços úteis.
O gatilho ocorre quando o cliente envia um frame HTTP/2 HEADERS e, imediatamente em seguida, um RST_STREAM com código de erro diferente de zero para o mesmo stream, antes de o multiplexador concluir o registro desse stream. Essa janela faz com que dois callbacks da biblioteca HTTP/2 sejam disparados em sequência: on_frame_recv_cb, associado ao recebimento do RST_STREAM, e on_stream_close_cb, associado ao fechamento do stream. Ambos convergem para a chamada h2_mplx_c1_client_rst, que por sua vez aciona m_stream_cleanup. Como o stream ainda está em uma condição intermediária, a limpeza é agendada duas vezes para o mesmo objeto.
A estrutura de limpeza afetada é o array spurge, usado posteriormente por c1_purge_streams. Quando essa rotina itera os itens pendentes, ela chama h2_stream_destroy, que termina em apr_pool_destroy. Na primeira passagem, o pool associado ao stream é destruído conforme esperado. Na segunda, o mesmo endereço já representa memória liberada, e a nova tentativa de destruição atinge um objeto que não possui mais validade. Em termos de exploração para indisponibilidade, essa condição basta para derrubar o worker. Como o padrão usa apenas frames HTTP/2 válidos e uma sequência curta, controles baseados apenas em tamanho de requisição, URL, método HTTP ou presença de cabeçalhos anômalos tendem a ter baixa eficácia.
O caminho de execução remota de código exige manipulação mais cuidadosa da memória liberada. A cadeia descrita para ambiente de laboratório reutiliza o endereço virtual liberado por meio de mmap, posiciona uma estrutura falsa compatível com h2_stream, aponta a função de limpeza do pool para system() e usa a memória de scoreboard do Apache como contêiner estável para estruturas falsas e para a string de comando. O scoreboard permanece em endereço fixo durante a vida do servidor, mesmo com ASLR, o que reduz uma parte da incerteza. Ainda assim, a exploração prática não é automática: é necessário obter vazamento de informação para localizar system() e offsets do scoreboard, e o spray de heap continua probabilístico.
A superfície principal são servidores Apache HTTP Server 2.4.66 que tenham HTTP/2 habilitado por meio de mod_http2 e operem com MPM multi-threaded. O cenário é comum em frentes web modernas, balanceadores reversos baseados em Apache, terminações TLS que negociam HTTP/2 e imagens de contêiner usadas para publicar aplicações internas ou externas. A falha não depende da aplicação hospedada, porque o problema acontece antes de qualquer lógica de negócio específica ser necessária. Também não há dependência de uma URL existente: o ponto crítico é o estado do stream dentro do tratamento HTTP/2.
Ambientes que usam MPM prefork foram indicados como não afetados pela falha, o que torna a identificação do MPM ativo parte essencial da priorização. Porém, a simples presença de Apache 2.4.66 em inventário não basta para medir risco: é necessário confirmar se mod_http2 está carregado, se HTTP/2 é negociado na interface exposta, se o servidor está atrás de proxy que preserva HTTP/2 até o backend e se a base usa APR com alocador mmap. Em contêineres, a avaliação deve incluir a imagem base, o pacote Apache instalado, a configuração de módulos e a forma como o tráfego chega ao processo httpd.
A correção está disponível no Apache HTTP Server 2.4.67. Em ambientes com janelas de manutenção rígidas, a redução temporária da superfície pode envolver desabilitar HTTP/2 onde o protocolo não for obrigatório, retirar exposição direta de instâncias vulneráveis e forçar terminação HTTP/2 em camada intermediária que não repasse HTTP/2 para o backend vulnerável. Essas medidas não substituem atualização, porque a falha está no binário e no módulo afetado, mas ajudam a reduzir a probabilidade de acionamento remoto enquanto a correção é implantada.
- Apache HTTP Server 2.4.66 com
mod_http2carregado e HTTP/2 habilitado. - MPM multi-threaded exposto a clientes capazes de negociar HTTP/2.
- Ambientes derivados de Debian e imagem oficial
httpdpara Docker quando o APR usa alocadormmap, no cenário de possível RCE. - MPM
preforkindicado como fora do escopo da falha.
A investigação deve começar pela confirmação de exposição. Operadores devem cruzar inventário de pacotes, configuração do Apache, módulos carregados e protocolos negociados em TLS para localizar instâncias 2.4.66 que aceitam HTTP/2. Em seguida, a telemetria de processo deve ser analisada para quedas de workers em sequência, reinicializações frequentes, interrupções de requisições simultâneas e aumento de erros sem correlação com carga legítima. Como o gatilho pode ocorrer com uma conexão curta e dois frames, logs de acesso podem ser incompletos ou pouco expressivos; a ausência de URL suspeita não elimina a hipótese.
Em rede, o sinal mais útil é a sequência de frames HTTP/2 em uma mesma conexão: HEADERS seguido imediatamente de RST_STREAM com código de erro diferente de zero no mesmo stream, especialmente quando repetido por um mesmo cliente ou por múltiplas origens com cadência automatizada. Sensores que decodificam HTTP/2, proxies com métricas por tipo de frame e capturas direcionadas em pontos de borda podem ajudar a distinguir erro legítimo de tentativa de exploração. Em hosts, eventos de crash do processo httpd, mensagens de falha associadas a destruição de memória e quedas de workers durante tráfego HTTP/2 devem ser correlacionados com timestamps de conexões externas.
Para o caminho de RCE, a detecção deve considerar sinais adicionais, não apenas o crash. Execução inesperada de processos filhos a partir do contexto do Apache, chamadas suspeitas que resultem em comandos de sistema, alterações em arquivos sob permissões do usuário do serviço e conexões de saída iniciadas pelo processo web após eventos de falha são indicadores de maior gravidade. Como a exploração descrita exige vazamento de informação e spray probabilístico, várias tentativas de crash antes de comportamento pós-exploração podem aparecer na mesma janela temporal.
- Negociação HTTP/2 seguida por
HEADERSeRST_STREAMcom código de erro diferente de zero no mesmo stream. - Crashes ou reinicializações de workers
httpdsem aumento proporcional de tráfego HTTP legítimo. - Perda de requisições em workers afetados durante conexões HTTP/2 curtas e repetitivas.
- Processos filhos, comandos de sistema ou conexões de saída originados do contexto do Apache após falhas de worker.
A ação principal é atualizar o Apache HTTP Server para 2.4.67, versão que corrige a falha. A atualização deve ser aplicada primeiro em servidores 2.4.66 com mod_http2 habilitado, exposição externa e MPM multi-threaded. Em ambientes com contêineres, não basta atualizar o pacote dentro de uma instância temporária: é necessário reconstruir imagens, revisar tags usadas em pipelines, publicar novas versões e substituir réplicas em execução. Depois da troca, a validação deve confirmar a versão efetiva do binário, os módulos carregados e a ausência de instâncias antigas ainda recebendo tráfego por trás de balanceadores.
Quando a atualização imediata não for possível, a contenção deve reduzir o alcance do vetor. Desabilitar HTTP/2 no Apache vulnerável, remover mod_http2 da configuração ativa ou terminar HTTP/2 em uma camada frontal que encaminhe HTTP/1.1 para o backend diminui a chance de exploração direta. Essa decisão deve ser testada contra clientes e integrações que dependam de HTTP/2, mas a prioridade técnica é impedir que clientes externos controlem frames HTTP/2 processados pelo módulo vulnerável. Mudanças de MPM podem alterar o risco, porém devem ser tratadas com cautela operacional, porque afetam concorrência, compatibilidade e desempenho.
Após a correção, a resposta deve incluir revisão retrospectiva. Equipes devem procurar crashes de workers no período anterior ao patch, identificar clientes que enviaram sequências anômalas de HTTP/2, verificar se houve execução de processos inesperados pelo usuário do Apache e revisar integridade de artefatos servidos pelo host. Se houver qualquer sinal compatível com pós-exploração, a contenção deve avançar para isolamento do servidor, coleta de evidências, rotação de segredos acessíveis ao processo web e reconstrução a partir de imagem confiável. A investigação precisa separar negação de serviço explorada com sucesso de tentativa de RCE, porque as evidências e o escopo de resposta são diferentes.
- Atualizar Apache HTTP Server 2.4.66 para 2.4.67 em todos os servidores e imagens afetadas.
- Confirmar se
mod_http2está carregado e se HTTP/2 é negociado em interfaces expostas. - Desabilitar HTTP/2 ou impedir repasse de HTTP/2 ao backend vulnerável quando a atualização exigir janela de manutenção.
- Correlacionar crashes de
httpdcom tráfego HTTP/2 e investigar execução de comandos ou conexões de saída no contexto do serviço. - Rebuildar imagens de contêiner, substituir réplicas antigas e validar que balanceadores não mantêm nós 2.4.66 ativos.
0 Comentários