Resumo para quem decide

A Apache Software Foundation corrigiu uma vulnerabilidade crítica no módulo mod_http2 do Apache HTTP Server, catalogada como CVE-2026-119618. Um atacante remoto, sem necessidade de autenticação, pode explorar uma condição de corrida para corromper memória e executar código arbitrário com os privilégios do processo do servidor web.

A falha só existe se o suporte a HTTP/2 estiver habilitado no servidor. Isso não é um alívio automático: segundo a Wiz, 64% dos ambientes em nuvem analisados têm recursos vulneráveis, e 51% dos ambientes analisados têm instâncias publicamente expostas na internet. Como o Apache HTTP Server roda em aproximadamente um em cada cinco sites do mundo, o volume absoluto de servidores potencialmente afetados é grande, segundo o BleepingComputer.

Não há exploit público conhecido nem relato de exploração ativa até agora. A própria Wiz avisa que isso pode mudar em breve. A ação recomendada é simples: atualizar para Apache HTTP Server 2.4.71 o quanto antes. Se isso não for possível de imediato, desabilitar o HTTP/2 na configuração remove o vetor de ataque até o patch ser aplicado.

O que é a CVE-2026-119618 e por que ela é crítica

A CVE-2026-119618 foi classificada como crítica pela Apache Software Foundation, conforme a página de vulnerabilidades do Apache HTTP Server 2.4. Não há nota CVSS numérica divulgada oficialmente. A Wiz é explícita sobre isso: avalia a severidade como crítica, mas reconhece que “nenhuma pontuação oficial está disponível”. Na prática, a classificação textual de “crítica” feita pela Apache e reforçada pela Wiz já é motivo suficiente para tratar a correção com prioridade alta, independente do número exato de CVSS.

A vulnerabilidade afeta o módulo mod_http2, responsável por implementar o suporte ao protocolo HTTP/2 no Apache. O problema é classificado tecnicamente como “Concurrent Execution using Shared Resource with Improper Synchronization”, ou seja, uma condição de corrida.

A condição de corrida no mod_http2 e o caminho até o RCE

O bug está na função assign_headers(). Quando threads concorrentes compartilham recursos sem sincronização adequada, um atacante remoto consegue disparar uma corrupção de heap. Essa corrupção de memória pode ser utilizada como primitiva para alcançar execução remota de código, com os privilégios do processo do servidor web, segundo a descrição técnica publicada pela Wiz.

As fontes não detalham o fluxo exato da condição de corrida, como quais threads entram em conflito, em que ordem, ou qual estrutura de dados específica do heap é corrompida. Também não há prova de conceito técnica publicada. O que se sabe com confiança é o resultado final: um atacante não autenticado, na rede, pode converter essa falha de sincronização em execução de código no servidor.

Quem descobriu: scanner de IA da Anthropic e pesquisadores do Google Cloud

A vulnerabilidade foi identificada de forma independente por duas frentes distintas e quase simultâneas. A primeira foi o “OSS Scanner” da Anthropic, uma ferramenta automatizada de varredura de código aberto, que catalogou o achado internamente como ANT-2026-MAPKT6MZ. A segunda foi o trabalho de Anthony Weems e Simon Scannell, pesquisadores do Google Cloud Vulnerability Research Team.

A linha do tempo divulgada pela Apache mostra os dois reportes em sequência próxima: o da Anthropic em 26 de outubro de 2026, o do Google em 3 de novembro de 2026. A correção chegou na branch 2.4.x via commit 824beab em 11 de novembro de 2026, mesma data do lançamento da versão 2.4.71.

Duas equipes diferentes, uma usando uma ferramenta de IA para varredura de código, outra usando análise manual de pesquisadores experientes, chegaram à mesma falha crítica em semanas de diferença. Isso ilustra uma mudança em curso na forma como vulnerabilidades em infraestrutura crítica de internet estão sendo encontradas, com ferramentas automatizadas de IA começando a operar lado a lado com pesquisa ofensiva humana tradicional. Já tratamos desse ângulo em mais detalhe no texto HTTP Terminator: IA e Zero-Day no Apache Explicados.

Quais sistemas estão em risco

Versões afetadas do Apache HTTP Server e do mod_h2 standalone

Duas linhas de código são afetadas:

• Apache HTTP Server: versões de 2.4.55 até 2.4.70.
• mod_h2 standalone (distribuído via GitHub, independente do pacote principal): versões de 2.0.8 até 2.0.42.

Se sua organização mantém builds customizados do mod_h2 fora do pacote oficial do Apache, vale checar essa segunda linha separadamente, já que ela segue um versionamento próprio.

Versões corrigidas e como confirmar se seu ambiente está exposto

A correção oficial está na versão Apache HTTP Server 2.4.71 e posteriores. Para quem usa o mod_h2 standalone do GitHub, a Wiz recomenda atualizar para uma versão posterior à 2.0.42. Vale registrar que há uma pequena inconsistência na própria divulgação da Wiz sobre esse ponto: a tabela de versões corrigidas lista “2.0.42 e mais recentes” como segura, mas o texto corrido do mesmo artigo recomenda migrar para “uma versão mais nova que 2.0.42”. Na dúvida, trate 2.0.42 como potencialmente vulnerável e busque uma versão estritamente posterior.

Nenhuma fonte oficial forneceu um comando pronto, seja via curl, nmap ou outro scanner, para verificar remotamente se uma instância está rodando uma versão vulnerável ou se o HTTP/2 está ativo. A verificação prática, portanto, passa por checar diretamente a versão instalada do pacote httpd ou apache2 no servidor, e revisar o arquivo de configuração em busca da diretiva Protocols. Clientes da Wiz podem usar uma consulta pré-construída e um advisório disponível no Wiz Threat Center para localizar instâncias vulneráveis no próprio ambiente em nuvem.

O fator decisivo: a falha só existe se o HTTP/2 estiver habilitado

Este é o ponto mais importante para decidir a urgência da correção. A configuração padrão do Apache HTTP Server vem com o HTTP/2 desabilitado. Pesquisadores da watchTowr também confirmaram que a exploração depende de o HTTP/2 estar habilitado, segundo o BleepingComputer.

O problema é que HTTP/2 é amplamente habilitado em produção por motivos de performance, especialmente em ambientes que servem muito tráfego HTTPS, usam multiplexação de conexões ou terminam TLS no próprio Apache. Isso cria um ponto cego comum em gestão de vulnerabilidades: equipes de segurança costumam auditar número de versão de software com disciplina, mas raramente auditam flags de configuração e protocolos ativos com o mesmo rigor. Saber que o Apache está na versão X não responde à pergunta real, que é se o HTTP/2 está ligado naquele servidor específico.

Esse mesmo padrão, onde a severidade real de uma falha depende de uma configuração de protocolo específica e nem sempre visível no inventário, também apareceu em outra falha recente envolvendo compressão HTTP/2 em múltiplas linguagens, descrita em HTTP2Shell: falha no Brotli afeta Node.js, Python e .NET. A recomendação da watchTowr resume bem a prioridade: “aplique o patch agora ou desative o h2 até conseguir aplicar.”

Qual é a exposição real: o que os dados da Wiz mostram

A Wiz levantou números de exposição a partir da telemetria de ambientes em nuvem que monitora:

• 64% dos ambientes em nuvem analisados possuem recursos com versões vulneráveis do Apache HTTP Server ou do mod_h2.
• 51% dos ambientes em nuvem analisados têm instâncias publicamente expostas na internet, ou seja, acessíveis a partir da rede externa sem controles adicionais de rede entre o atacante e o servidor.

É importante entender o que esses números não dizem. Eles medem presença de versão vulnerável e exposição de rede, mas não confirmam se o HTTP/2 está de fato habilitado nessas instâncias. Como visto na seção anterior, essa é a condição que decide se a falha é explorável ou não. Na prática, isso significa que o número real de instâncias efetivamente exploráveis é, provavelmente, menor do que sugerem os 51% de ambientes com exposição pública, mas não há como saber quanto menor sem auditar a configuração de protocolo de cada instância.

As fontes não trazem contagem absoluta de servidores afetados na internet, nem dados de ferramentas externas de varredura ampla como Shodan ou Censys. Os percentuais divulgados refletem apenas o universo de telemetria da própria Wiz. Ainda assim, dado o alcance do Apache HTTP Server, estimado em um em cada cinco sites da internet pelo BleepingComputer, mesmo uma fração desse universo representa um volume relevante de servidores expostos. Um cenário parecido de exposição em massa, onde um número alto de instâncias públicas ficou vulnerável por falta de atualização, apareceu recentemente em Mais de 1.000 servidores GitLab vulneráveis à CVE-2026-97229.

Como corrigir e mitigar agora

Atualizar para a versão corrigida (2.4.71 ou mod_h2 pós-2.0.42)

A correção oficial e definitiva é atualizar o Apache HTTP Server para a versão 2.4.71 ou posterior. Para instalações que usam o mod_h2 standalone obtido via GitHub, a atualização deve ir para uma versão posterior à 2.0.42.

Vale lembrar que a versão 2.4.71 também corrige outras duas falhas publicadas na mesma janela:

• CVE-2026-106023: falha classificada como importante pela Apache, um NULL pointer dereference no mod_md durante o processamento de requisições HTTP, que pode derrubar o processo filho do servidor. Afeta versões de 2.4.30 até 2.4.70.
• CVE-2026-109163: falha de baixa severidade, uma sobrescrita de 1 byte em buffer de pilha no mod_vhost_alias, sequência de uma falha anterior (CVE-2026-63292). Afeta as versões 2.4.69 e 2.4.70.

Atualizar para 2.4.71 resolve as três de uma vez, então não há motivo para tratar a CVE-2026-119618 isoladamente se o processo de patch já vai mexer na versão do pacote.

Workaround temporário: desabilitar HTTP/2 na configuração

Se a atualização imediata não for viável, a mitigação recomendada pela Wiz é desabilitar o suporte a HTTP/2 no arquivo de configuração do Apache, por exemplo em httpd.conf, restringindo os protocolos ativos apenas a HTTP/1.1:

# Restrict protocols to HTTP/1.1
Protocols http/1.1

Essa diretiva remove as referências a h2 e h2c da negociação de protocolo do servidor, eliminando o vetor de ataque enquanto o patch definitivo não é aplicado. É uma mitigação temporária, não um substituto para a atualização, já que remove uma funcionalidade de performance que pode estar sendo usada ativamente por outros motivos na aplicação.

Por que não esperar: a janela antes da exploração ativa

Até o momento da divulgação, não há exploit público conhecido nem relatos de exploração ativa dessa falha. A própria Wiz é cautelosa ao registrar isso: “não há exploits públicos ou ataques direcionados à falha” no momento, “mas isso pode mudar em breve.”

Essa janela entre a divulgação do patch e o surgimento do primeiro exploit público é exatamente o período em que a correção custa menos e evita mais dano. Uma vez que um PoC circule publicamente, CVEs com esse perfil (atacante remoto não autenticado, RCE, software extremamente difundido) costumam virar alvo de varredura em massa em questão de dias. O histórico recente de outras falhas críticas em servidores expostos, como o zero-day do BIG-IP APM da F5 (CVE-2026-94127), já explorado ativamente antes mesmo de qualquer patch estar disponível, e o RCE crítico no interpretador PHP tratado em PHP2Shell, mostra como a velocidade de resposta faz diferença real. Vale conferir também o caso da F5 em BIG-IP APM da F5: zero-day já explorado permite RCE sem autenticação, um lembrete de como o cenário pode piorar rápido quando o atacante já está na frente da defesa.

Para a CVE-2026-119618, a ordem prática de prioridade é: primeiro, levantar inventário de onde o Apache HTTP Server está rodando e em que versão. Segundo, checar, servidor a servidor, se a diretiva Protocols ou qualquer configuração equivalente habilita HTTP/2. Terceiro, aplicar o patch para 2.4.71 nos servidores críticos e expostos publicamente, mesmo que o HTTP/2 esteja desabilitado hoje, já que configurações mudam e a atualização resolve de forma permanente. Quarto, onde o patch não puder ser aplicado de imediato, desabilitar o HTTP/2 como mitigação temporária.

Perguntas frequentes

Meu servidor Apache está vulnerável mesmo sem HTTP/2 habilitado?
Não. A exploração da CVE-2026-119618 depende do módulo mod_http2 estar processando tráfego HTTP/2 ativamente. Se o protocolo estiver desabilitado, o vetor de ataque não está disponível, mesmo que a versão instalada do Apache esteja na faixa vulnerável.

Como sei se o HTTP/2 está habilitado no meu servidor?
As fontes oficiais não trazem um comando pronto de verificação remota. A forma prática é revisar o arquivo de configuração do Apache, procurando pela diretiva Protocols e por referências a h2 ou h2c. Ausência dessas referências, com http/1.1 como único protocolo listado, indica que o HTTP/2 não está ativo.

Preciso atualizar mesmo se eu desabilitar o HTTP/2 agora?
Sim. Desabilitar o HTTP/2 é tratado pela própria Wiz como mitigação temporária, não como correção definitiva. A atualização para a versão 2.4.71 remove a vulnerabilidade de forma permanente e também corrige as outras duas falhas publicadas na mesma versão.

Já existe exploit público para essa falha?
Não, segundo a Wiz e o BleepingComputer, não havia exploit público conhecido nem relatos de exploração ativa até o momento da divulgação. Ambas as fontes alertam que essa situação pode mudar rapidamente.

Quem descobriu a vulnerabilidade?
Foi identificada de forma independente pelo scanner automatizado de código aberto da Anthropic e por pesquisadores do Google Cloud Vulnerability Research Team, Anthony Weems e Simon Scannell, com reportes à Apache em datas próximas, em outubro e novembro de 2026.

O que fazer se eu uso o mod_h2 standalone em vez do pacote oficial do Apache?
Atualizar para uma versão posterior à 2.0.42, disponível no repositório do projeto no GitHub. Há uma leve ambiguidade na divulgação sobre se a própria versão 2.0.42 já está corrigida ou ainda é vulnerável, então o mais seguro é migrar para uma versão estritamente mais nova que essa.