Falha HTTP/2 do Apache CVE-2026-119618: atualize para 2.4.71

O que é a CVE-2026-119618?

A CVE-2026-119618 é uma vulnerabilidade crítica no mod_http2, o módulo que trata o tráfego HTTP/2 no Apache HTTP Server; ela pode levar à corrupção do heap e à execução remota de código ^[1].

A Apache a descreve como uma “vulnerabilidade de execução concorrente com uso de recurso compartilhado e sincronização inadequada no mod_http2 do Apache HTTP Server, em assign_headers()” que “pode levar a RCE” ^[1]. O CIRCL, equipe nacional de resposta a emergências de computação de Luxemburgo, explica que, durante o processamento simultâneo de fluxos HTTP/2, um worker pode modificar uma tabela de cabeçalhos alocada para outro contexto de execução, e esse acesso inseguro à memória compartilhada pode corromper o heap ^[2].

Um atacante bem-sucedido poderia executar código com os privilégios do processo do servidor web Apache, sem precisar fazer login ^[2][4]. Estima-se que o Apache HTTP Server esteja em cerca de um em cada cinco sites, segundo o BleepingComputer ^[4].

A correção do projeto original altera uma única gravação em modules/http2/h2_request.c, trocando a tabela de cabeçalhos de requisição compartilhada pelos cabeçalhos de entrada da própria requisição atual ^[2].

Quais versões do Apache são afetadas?

O Apache HTTP Server 2.4.55 até 2.4.70 é afetado, assim como as versões independentes do mod_h2 de 2.0.8 a 2.0.42 do GitHub; a versão 2.4.71 corrige o problema ^[1].

Os pacotes das distribuições complicam a verificação de versão. O CIRCL aconselha as organizações que usam pacotes mantidos por distribuidores a verificar o backport de segurança em vez de confiar apenas no número da versão original ^[2]. A Red Hat, segundo o resumo do CIRCL, classifica seus pacotes RHEL 9 e 10 como Importante, e não Crítico, porque o alocador de memória deles dificulta a exploração, e informa que o RHEL 8 e anteriores não são afetados ^[2].

A Red Hat atribui uma pontuação CVSS v3.1 geral de 9,8 (Crítica) ^[2][3]. A classificação da própria Apache é Crítica ^[1].

Meu servidor Apache é vulnerável?

Somente se executar uma build afetada e aceitar de fato conexões HTTP/2: a Red Hat diz que servidores configurados para atender apenas HTTP/1.1 não são vulneráveis ^[3]. O CIRCL ressalta que o caminho do código não é alcançável apenas porque o mod_http2 está instalado ou carregado ^[2].

• A diretiva Protocols controla o HTTP/2: “h2” o ativa sobre TLS e “h2c” sobre texto simples ^[2].
• O padrão do núcleo do Apache é http/1.1, e carregar o mod_http2 não muda isso por si só ^[2]. O BleepingComputer observa que o HTTP/2 vem desativado por padrão ^[4].
• Um virtual host pode definir sua própria diretiva Protocols, então verificar apenas a configuração global pode deixar passar um site com HTTP/2 ativado ^[2].
• Se um proxy reverso, balanceador de carga ou CDN encerra o HTTP/2 e encaminha apenas HTTP/1.1 ao Apache, a sessão HTTP/2 do cliente não torna o Apache alcançável por si só, mas é preciso verificar o protocolo em cada salto ^[2].

O CIRCL sugere revisar a versão e os módulos carregados (apachectl -v, apachectl -M), os virtual hosts configurados (apachectl -S) e cada configuração explícita de Protocols ^[2]. Um teste que mostra que um endpoint aceita HTTP/2 não prova que o backend dele é vulnerável, e um teste negativo não prova que todas as portas ou virtual hosts rejeitam o HTTP/2 ^[2].

Como verificar se meu servidor aceita HTTP/2?

O CIRCL sugere duas verificações: revisar a configuração do Apache no próprio servidor e depois testar o protocolo negociado pela rede, de preferência conectando-se diretamente ao Apache e não por um proxy ^[2].

1. Verifique a versão e os módulos. Execute apachectl -v para ver a versão e apachectl -M, filtrado por http2, para ver se o módulo está carregado ^[2].
2. Liste os virtual hosts. apachectl -S mostra todos os virtual hosts configurados, o que importa porque cada um pode ter sua própria linha Protocols ^[2].
3. Encontre todas as diretivas Protocols. O CIRCL traz um comando grep que procura em /etc/apache2 e /etc/httpd configurações explícitas de Protocols, incluindo substituições em virtual hosts; os caminhos variam conforme a distribuição ^[2].
4. Teste sobre TLS. Uma requisição curl com a opção --http2 que imprime a versão do HTTP mostra se um endpoint HTTPS negocia HTTP/2 ^[2].
5. Teste em texto simples. curl com --http2-prior-knowledge verifica se um endpoint HTTP simples aceita h2c ^[2].

Leia os resultados com cuidado. Uma resposta que informa HTTP/2 mostra que o endpoint testado aceitou HTTP/2, mas não confirma que o backend Apache dele seja vulnerável; um resultado negativo não prova que todos os endereços, portas ou virtual hosts o rejeitam ^[2]. A recomendação do CIRCL é confirmar em conjunto a configuração efetiva do Apache e o status do pacote corrigido do fornecedor ^[2]. Em ambientes de nuvem, a Wiz alerta que uma instância Apache comprometida pode virar um ponto de entrada para movimentação lateral até microsserviços próximos ou endpoints de metadados da nuvem, o que é mais um motivo para verificar todas as instâncias e não apenas o site público ^[5].

Como corrigir a CVE-2026-119618?

Atualize para o Apache HTTP Server 2.4.71 ou posterior, ou instale o pacote corrigido da sua distribuição, depois reinicie o Apache e confirme que os processos em execução usam a nova build ^[2][1].

1. Atualize o Apache. Instale a 2.4.71 ou uma build do fornecedor corrigida explicitamente para a CVE-2026-119618 ^[2].
2. Atualize o mod_h2 independente se você o usa, conforme orientação do fornecedor; a Wiz diz para passar da versão 2.0.42, enquanto o CIRCL alerta para não presumir que exista uma versão independente mais nova sem verificar ^[5][2].
3. Reinicie e verifique se os processos em execução usam a build corrigida ^[2].
4. Se ainda não puder atualizar, desative o HTTP/2: defina Protocols como http/1.1, remova h2 e h2c de todo virtual host que substitua a configuração, teste com apachectl -t e recarregue ^[2]. Isso bloqueia o caminho desta falha, mas não corrige o código ^[2].
5. Restrinja o acesso a redes confiáveis como medida provisória quando não for possível nem atualizar nem alterar protocolos ^[2].

Pesquisadores da watchTowr resumiram assim: “atualize agora ou desative o h2 até poder”, relata o BleepingComputer ^[4]. O SecurityWeek relata que a Defiant também alertou que as atualizações de segurança do WordPress não resolvem o problema, porque ele afeta o servidor web subjacente ^[3].

A CVE-2026-119618 está sendo explorada?

Até a publicação da Wiz em 11 de novembro de 2026, não havia exploit disponível nem relatos de exploração ativa ^[5]. O quadro, porém, muda rápido.

• A Red Hat diz que pesquisas públicas demonstraram um exploit confiável contra um servidor com mod_http2 ativado, mas seu comunicado não identifica a pesquisa ^[3]. O CIRCL observa que isso, por si só, não comprova exploração ativa ^[2].
• Uma prova de conceito pública no GitHub afirma reproduzir corrupção de memória e travamentos do Apache, mas não demonstra execução remota de código ^[3].
• Dados da Wiz mostram que 64% dos ambientes de nuvem têm recursos executando versões afetadas e 51% têm instâncias expostas publicamente; a Wiz observa que isso não leva em conta a configuração, então não são necessariamente sistemas exploráveis ^[5][3].

O CIRCL lista sinais que valem investigação: travamentos inesperados de workers, reinicializações anormais, processos filhos suspeitos, alterações não autorizadas em arquivos e conexões de saída inesperadas ^[2]. São pistas, não indicadores confirmados de comprometimento, e a atualização não remove a persistência instalada antes dela ^[2].

Quem descobriu a falha HTTP/2 do Apache?

A Apache credita o OSS Scanner da Anthropic, que reportou a falha em 26 de outubro de 2026, e Anthony Weems e Simon Scannell, do Google Cloud Vulnerability Research, que a reportaram de forma independente em 3 de novembro ^[1].

A descoberta da Anthropic consta sob o identificador interno ANT-2026-MAPKT6MZ ^[1]. O SecurityWeek descreve os dois relatos como descobertas independentes ^[3]. É mais um exemplo de ferramentas automatizadas e assistidas por IA encontrando bugs graves em software de código aberto amplamente usado; IA que encontra falhas de segurança: o que o Glasswing e as novas CVEs significam para você analisa o que essa tendência representa.

A correção foi integrada e a 2.4.71 foi lançada em 11 de novembro, o mesmo dia em que a Apache divulgou o problema na lista de discussão oss-security ^[1][2].

O que mais a Apache 2.4.71 corrige?

O Apache HTTP Server 2.4.71 corrige três CVEs no total: uma crítica, uma importante e uma baixa ^[1].

• CVE-2026-106023 (importante): uma desreferência de ponteiro NULL no mod_md durante o processamento de requisições que pode derrubar um processo filho; afeta de 2.4.30 a 2.4.70 ^[1].
• CVE-2026-109163 (baixa): uma sobrescrita de um byte no buffer da pilha no mod_vhost_alias, que a Apache rotula como “após a CVE-2026-63292” (essa falha anterior foi corrigida na 2.4.69); afeta a 2.4.69 e a 2.4.70 ^[1].

A versão anterior, a 2.4.69, de outubro de 2026, corrigiu 20 CVEs ^[1]. Os administradores que a pularam recebem essas correções também ao passar para a 2.4.71. Para outra falha recente em servidores, veja CVE-2026-98432 explicada: a falha TCP do Linux e como proteger seus servidores.

O que os administradores devem acompanhar a seguir?

Fique atento a um exploit público de execução remota de código, a backports dos fornecedores para a sua distribuição e a quaisquer relatos de ataques em andamento ^[3][5].

O CIRCL recomenda inventariar as instâncias com HTTP/2 ativado, verificar se cada build do mod_http2 é afetada e atualizar sem demora os sistemas expostos, com prioridade para sites e APIs voltados para a internet, hospedagem compartilhada e servidores Apache atrás de frontends que encaminham HTTP/2 ^[2]. As organizações que virem atividade suspeita devem seguir seus procedimentos de resposta a incidentes e contatar o CSIRT nacional ^[2].