Seguir 
A Apache corrigiu o CVE-2026-23918, uma falha crítica no manuseio de HTTP/2 do Apache HTTP Server que a Apache descreve como um “double free e possível RCE.” O problema afeta o Apache HTTP Server 2.4.66 e foi corrigido na versão 2.4.67, lançada em 4 de maio de 2026.
A vulnerabilidade CVE-2026-23918 é importante porque pode ser explorada remotamente e sem autenticação. Relatórios públicos dizem que o bug pode causar uma condição de negação de serviço e, sob certas condições, também pode abrir um caminho para execução remota de código, tornando-se um dos problemas mais graves abordados no mais recente lançamento de segurança da Apache.
A Apache credita Bartlomiej Dmitruk da striga.ai e Stanislaw Strzalkowski da isec.pl por reportarem a falha. A própria página de vulnerabilidades da Apache mostra que foi reportada à equipe de segurança em 10 de dezembro de 2025, corrigida no código-fonte em 11 de dezembro de 2025, e entregue aos usuários na versão 2.4.67 meses depois.
Análise do CVE-2026-23918
De acordo com a Apache e comentários de pesquisadores citados pelo The Hacker News, o bug é um double-free no mod_http2, especificamente no caminho de limpeza do stream. Ele pode ser acionado quando um cliente envia um quadro HTTP/2 HEADERS e então imediatamente envia RST_STREAM com um código de erro não zero antes que o stream seja totalmente registrado pelo multiplexador.
Essa sequência pode causar a execução de dois callbacks de maneira que empurra o mesmo objeto stream para o array de limpeza duas vezes. Quando a Apache mais tarde destrói as entradas do stream, a memória que já foi liberada é liberada novamente. Em termos práticos, a vulnerabilidade no CVE-2026-23918 é uma falha de gerenciamento de memória que pode travar processos de trabalho e, no ambiente certo, ser moldada em uma execução de código.
O caminho de negação de serviço parece ser o resultado mais fácil. Os pesquisadores disseram ao The Hacker News que uma conexão TCP e dois quadros HTTP/2 são suficientes para travar um trabalhador em implantações padrão que usam mod_http2 com um MPM multithread. Eles também notaram que o MPM prefork não é afetado, enquanto o possível caminho de RCE depende de uma configuração APR usando o alocador mmap, que é dito ser o padrão em sistemas derivados do Debian e na imagem oficial do Docker do httpd.
Quanto à maturidade da exploração, relatórios públicos dizem que os pesquisadores construíram um poc funcional para CVE-2026-23918 para x86_64 em condições de laboratório. Eles também disseram que a exploração prática ainda precisa de condições auxiliares, como um vazamento de informações e reutilização favorável de memória, então a execução de código é mais exigente do que a simples interrupção do serviço.
Neste estágio, detalhes públicos para o CVE-2026-23918 apontam muito mais claramente para travamentos de processo e instabilidade de trabalhadores do que para uma RCE amplamente reproduzível no campo. Também não há iocs publicados por fornecedores para CVE-2026-23918, então os defensores devem se concentrar na exposição da versão, travamentos inesperados de trabalhadores e padrões suspeitos de reset em HTTP/2, em vez de um conjunto estável de assinaturas.
Mitigação do CVE-2026-23918
A correção principal é atualizar o Apache HTTP Server da versão 2.4.66 para a versão 2.4.67. O aviso de segurança do Apache recomenda explicitamente a mudança para a versão corrigida, e o SecurityWeek observa que a versão corrige 11 vulnerabilidades, incluindo este problema crítico de HTTP/2.
Para triagem imediata, os defensores devem identificar sistemas voltados para a internet onde mod_http2 está habilitado e onde MPMs com suporte a threads estão em uso. Essa é a maneira mais prática de detectar a exposição ao CVE-2026-23918, porque o ataque depende do manuseio de solicitações HTTP/2, não de um artefato de malware descartado ou beacon tradicional de pós-exploração.
Se o remendo de emergência for adiado, reduzir a exposição ao tráfego HTTP/2 pode ajudar a diminuir a superfície de ataque até que as atualizações sejam aplicadas. A carga útil do CVE-2026-23918 descrita publicamente não é um arquivo ou binário convencional, mas uma sequência elaborada de quadros HTTP/2 projetada para forçar o caminho de limpeza defeituoso, então instâncias Apache voltadas para a rede devem ser priorizadas primeiro.
Do ponto de vista do risco, o CVE-2026-23918 afeta organizações que dependem do Apache HTTP Server 2.4.66 para cargas de trabalho web públicas, especialmente onde HTTP/2 é ativado por padrão ou amplamente implantado por razões de desempenho. Isso inclui servidores web padrão baseados em Linux, bem como implantações em contêineres usando a imagem oficial do Apache.
FAQ
O que é o CVE-2026-23918 e como ele funciona?
É uma falha crítica de double-free no manuseio de HTTP/2 do Apache HTTP Server. Uma sequência de quadros HTTP/2 especialmente cronometrada pode empurrar o mesmo objeto stream para a limpeza duas vezes, levando a travamentos de trabalhadores e potencialmente possibilitando a execução remota de código sob condições favoráveis.
Quando o CVE-2026-23918 foi descoberto pela primeira vez?
A página de vulnerabilidades da Apache diz que o problema foi relatado à equipe de segurança em 10 de dezembro de 2025. A correção foi implementada no código-fonte em 11 de dezembro de 2025 e a versão corrigida 2.4.67 foi publicada em 4 de maio de 2026.
Qual é o impacto do CVE-2026-23918 nos sistemas?
O impacto mais imediato é a negação de serviço através de trabalhadores Apache travados. Relatórios públicos também dizem que a falha pode permitir a execução remota de código, embora esse caminho pareça mais complexo e dependente do ambiente do que o cenário de travamento.
O CVE-2026-23918 ainda pode me afetar em 2026?
Sim. Os sistemas podem ainda estar expostos em 2026 se estiverem executando o Apache HTTP Server 2.4.66 com mod_http2 ativado e ainda não tiverem sido atualizados para 2.4.67. O risco é especialmente relevante para implantações que utilizam MPMs thread.
Como posso me proteger do CVE-2026-23918?
Atualize para o Apache HTTP Server 2.4.67 o mais rápido possível, identifique implantações expostas com HTTP/2 habilitado e priorize servidores externamente acessíveis para remediação. Onde a aplicação de patches não pode acontecer imediatamente, reduzir a exposição ao HTTP/2 pode ajudar a diminuir o risco a curto prazo.
