CVE-2026-119618: falha crítica no mod_http2 do Apache

O projeto Apache HTTP Server publicou em 11 de novembro de 2026 a correção da CVE-2026-119618, uma falha crítica no módulo mod_http2 que pode levar à execução remota de código sem autenticação. A versão corretiva é a 2.4.71, lançada no mesmo dia.

O problema é uma condição de corrida: threads concorrentes acessam um recurso compartilhado sem sincronização adequada e corrompem a memória do processo filho. Quem explorar isso executa código com os privilégios do processo do servidor web — e o httpd responde por cerca de um em cada cinco sites, segundo estimativas de mercado.

Dois detalhes separam esse caso da rotina. O primeiro é quem achou: a falha foi reportada por um scanner de código aberto baseado em IA e redescoberta por pesquisadores humanos oito dias depois. O segundo é que a exposição não se mede pela versão instalada, e sim por uma condição de configuração.

O que é a falha

A descrição oficial do projeto Apache é direta: “vulnerabilidade de execução concorrente usando recurso compartilhado com sincronização imprópria” na função assign_headers() do mod_http2, levando a execução remota de código. O título interno do aviso é ainda mais explícito: corrupção de heap e RCE em assign_headers.

A classificação é CWE-362 (execução concorrente com sincronização imprópria); o NVD também registra CWE-20. O CVSS v3.1 é 9,8 (crítico), vetor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — rede, baixa complexidade, sem privilégios e sem interação. O EPSS está abaixo de 1% e a falha não consta do KEV da CISA.

Sobre o mecanismo, convém separar o que o fornecedor confirma do que é reconstrução de terceiros. A Red Hat confirma um ponto técnico relevante: no RHEL 9 e 10 a falha é classificada como Importante em vez de Crítica porque, nesses pacotes, cada fluxo HTTP/2 recebe seu próprio alocador. A corrida depende, portanto, de fluxos concorrentes compartilharem o alocador da conexão. Análises públicas independentes descrevem o gatilho como a escrita de um Content-Length sintetizado numa tabela de fluxos compartilhada, mas isso não é afirmação oficial do projeto.

Versões afetadas e correção

O aviso oficial do Apache não lista contorno — a remediação indicada é a atualização. O projeto também não informa versão corrigida do mod_h2 autônomo distribuído pelo GitHub, de modo que quem usa esse módulo separado precisa acompanhar o repositório dele diretamente. A mesma versão 2.4.71 corrige ainda outras duas falhas de menor gravidade: a CVE-2026-106023, de desreferência de ponteiro nulo no mod_md, e a CVE-2026-109163, de sobrescrita de dados no mod_vhost_alias.

Como saber se você está exposto

Este é o ponto que mais muda a conta. Servidores que atendem apenas em HTTP/1.1 não são vulneráveis: a falha exige que o HTTP/2 esteja efetivamente habilitado. Ter o módulo instalado não basta — é preciso que ele esteja carregado e que a diretiva Protocols inclua h2 ou h2c, algo que varia bastante conforme a distribuição e a forma de empacotamento.

Verificações defensivas úteis:

• Conferir os módulos carregados: apachectl -M | grep http2.
• Conferir a diretiva Protocols na configuração efetiva, incluindo includes e hosts virtuais.
• Sondar o ALPN na borda, para confirmar se o h2 é de fato negociado no handshake TLS.
• Verificar se WAFs e proxies reversos repassam HTTP/2 para a origem, em vez de terminar o protocolo na borda.
• Em contêineres, checar as camadas base: imagens fixadas em digests antigos seguem vulneráveis após a correção do fornecedor.

Descoberta por IA — e por que isso importa aqui

O crédito do aviso oficial lista duas origens independentes. O OSS Scanner da Anthropic, ferramenta automatizada de varredura de código aberto, reportou a falha em 26 de outubro de 2026, sob o identificador interno ANT-2026-MAPKT6MZ. Em 3 de novembro, Anthony Weems e Simon Scannell, da equipe de pesquisa de vulnerabilidades do Google Cloud, reportaram o mesmo problema de forma independente. A correção saiu em 11 de novembro — 16 dias após o primeiro relato.

A Cloud Security Alliance publicou em 12 de novembro uma nota de pesquisa justamente sobre esse ponto. O argumento é que duas descobertas independentes em cerca de uma semana encurtam a janela de segurança que a divulgação coordenada pressupõe: se duas equipes chegam ao mesmo bug em oito dias, a probabilidade de um terceiro — não necessariamente bem-intencionado — ter chegado antes deixa de ser desprezível. A CSA informa não ter localizado a pesquisa primária de exploração e, à época, nenhum relato de exploração em campo.

A mesma nota traz um contraponto sobre o volume gerado por varredura automatizada: em levantamento anterior da própria CSA, de 1.596 vulnerabilidades descobertas por IA e reportadas a mantenedores, apenas 97 haviam sido corrigidas. Achar mais rápido não significa corrigir mais rápido — dinâmica que o Plugged Ninja já registrou em julho, com uma falha de HTTP/2 em produtos da Citrix atribuída a descoberta automatizada.

Exposição e estado da exploração

Segundo telemetria da Wiz citada pelo BleepingComputer, 64% dos ambientes de nuvem analisados têm recursos vulneráveis, e cerca de metade deles tem instâncias expostas publicamente. Com uma ressalva que a própria reportagem registra: o número não considera a configuração do servidor, ou seja, mede presença de versão afetada, não exposição explorável.

A Wiz classificou a gravidade como crítica e, em 12 de novembro, afirmou não ter conhecimento de exploits públicos ou de ataques direcionados à falha. Pesquisadores da watchTowr confirmaram a dependência de configuração e resumiram a recomendação em uma frase: corrigir agora ou desligar o h2 até conseguir corrigir.

Esse quadro já mudou em parte. Na verificação feita por esta redação em 13 de novembro de 2026, havia ao menos um repositório público, atualizado em 12 de novembro, anunciando prova de conceito funcional com laboratório em contêiner, evidências de instrumentação de memória e de threads, e comparação diferencial com a 2.4.71. O Plugged Ninja não divulga o endereço desse repositório, mas o registra porque o dado altera a prioridade de correção: a janela entre PoC público e varredura em massa costuma ser curta — a execução recente contra o N-able N-central, explorada horas depois da publicação de uma PoC, é o exemplo mais próximo. Até o fechamento deste texto, não há relato verificado de exploração em campo da CVE-2026-119618.

O descompasso entre as distribuições

O levantamento da CSA, feito em 12 de novembro, aponta estados diferentes por distribuição: no Debian, trixie e sid constavam corrigidos, enquanto bookworm ainda aparecia como vulnerável e ausente do aviso DSA correspondente; na Red Hat, RHEL 9 e 10 apareciam como afetados e classificados como Importante, sem errata listada no momento da revisão; e, para o Ubuntu, a CSA não localizou página de CVE nem aviso de segurança.

Há um efeito colateral prático: distribuições corporativas aplicam backport da correção sem alterar o número de versão do pacote. Varredura baseada em string de versão passa então a produzir falso positivo em pacotes já corrigidos e a deixar exposição real sem apontar. A validação confiável é por changelog do pacote ou identificador de errata.

Impactos, possibilidades e limitações

O pior caso é sério: execução remota de código sem autenticação em um serviço de borda, com os privilégios do processo do servidor web. Em hospedagem compartilhada ou em servidores que terminam TLS para vários hosts virtuais, comprometer o processo filho tende a significar acesso a tudo o que ele enxerga.

Do lado atenuante, há três fatores concretos. A exploração depende de configuração — HTTP/2 negociado —, o que exclui uma parcela relevante do parque. Condições de corrida são, em geral, menos confiáveis de explorar do que estouros determinísticos, porque dependem de temporização. E, no caso específico dos pacotes do RHEL 9 e 10, a própria Red Hat aponta uma diferença de arquitetura de memória que reduz o impacto — razão pela qual a classificação local é Importante, embora a pontuação CVSS seja 9,8.

As limitações do que se sabe também precisam ficar claras. Não há pesquisa primária de exploração publicada pelos descobridores, o percentual de 64% da Wiz mede presença de versão e não exposição efetiva, e não existe número público confiável de servidores com HTTP/2 realmente habilitado entre os afetados. O estado das erratas por distribuição é um retrato de 12 de novembro e muda rápido: convém reconsultar o rastreador da sua distribuição.

Recomendações

• Atualizar para o Apache HTTP Server 2.4.71 ou superior, ou aplicar o pacote corrigido da sua distribuição, tratando a mudança como emergencial. Reiniciar o httpd depois.
• Mitigação provisória, onde ainda não há pacote corrigido: definir Protocols http/1.1 ou descarregar o mod_http2. Antes, confirmar que nada depende de HTTP/2 — back-ends gRPC e caminhos h2c quebram com essa mudança.
• Validar a correção por changelog ou errata, nunca apenas pelo número da versão, por causa do backport.
• Checar o mod_h2 autônomo (versões 2.0.8 a 2.0.42) separadamente, já que o aviso do Apache não indica versão corrigida para ele.
• Habilitar e preservar registros do servidor; em caso de suspeita, considerar o processo do servidor web como potencialmente comprometido e tratar credenciais e chaves acessíveis a ele como expostas.

Conclusão

A CVE-2026-119618 é um boletim crítico com uma ressalva de configuração que muda a conta de risco — e por isso o trabalho mais útil agora é de inventário. Quem não negocia HTTP/2 não está exposto; quem negocia está diante de uma RCE pré-autenticação na borda, com prova de conceito já circulando.

O que observar a seguir: a publicação de erratas pelas distribuições que ainda estavam pendentes, a eventual entrada da falha no catálogo KEV da CISA, e o primeiro relato verificado de exploração em campo. No pano de fundo, fica a discussão aberta pela nota da CSA — quando duas equipes independentes encontram o mesmo bug em oito dias, o calendário da divulgação coordenada passa a merecer revisão.

Fontes e referências

• Apache HTTP Server Project — página oficial de vulnerabilidades do ramo 2.4, com o registro da CVE-2026-119618 — httpd.apache.org
• oss-security — aviso original enviado pelo projeto Apache em 11 de novembro de 2026 — openwall.com
• Red Hat — página oficial da CVE-2026-119618, com a classificação por produto e a condição da diretiva Protocols — access.redhat.com
• OpenCVE — registro consolidado da CVE, com CVSS, CWE, EPSS e referências — app.opencve.io
• Cloud Security Alliance — “CVE-2026-119618: AI-Discovered Apache HTTP/2 RCE and the Distribution Patch Gap”, 12 de novembro de 2026 — labs.cloudsecurityalliance.org
• BleepingComputer — “Apache HTTP Server patches critical HTTP/2 remote code execution flaw”, com a telemetria da Wiz e a avaliação da watchTowr — bleepingcomputer.com