Apache corrige na versão 2.4.71 falha que permite executar código sem autenticação

Se o Apache atende seu site ou sua API via HTTP/2, a equipe de infraestrutura tem uma tarefa urgente: verificar a versão e instalar a correção. Uma falha no módulo que processa esse protocolo permite que um invasor execute código sem autenticação. Por exemplo, o servidor que fica à frente da sua aplicação pode estar em risco: esse ataque não exige a senha do painel administrativo.

O Apache lançou a correção em 11 de novembro, na versão 2.4.71. A vulnerabilidade recebeu o identificador CVE-2026-119618 e foi classificada como crítica. Segundo o aviso oficial do Apache, as versões afetadas são 2.4.55–2.4.70. É um motivo concreto para consultar o inventário de servidores, identificar onde o HTTP/2 é usado e definir um responsável pela atualização.

O que falhou dentro do servidor

A falha está no mod_http2, na função assign_headers(). Várias threads acessam recursos compartilhados sem a sincronização adequada. Como resultado, o servidor pode corromper a própria memória, e um invasor pode explorar essa corrupção para executar código.

Imagine dois funcionários editando simultaneamente a mesma linha de um pedido. Um altera o conteúdo enquanto o outro continua trabalhando com o estado anterior. Para um servidor web, essa falta de coordenação é perigosa: ela envolve a memória de um processo em execução. Essa é uma analogia simplificada da causa da falha, não a descrição de um método de ataque pronto para uso.

Um exemplo prático é o Apache à frente de um serviço de assinatura. Mesmo que o acesso à conta seja protegido por autenticação multifator, o processamento do protocolo de rede ocorre antes de a aplicação autenticar o usuário. Por isso, reforçar as senhas não resolve esse problema específico. A equipe precisa corrigir o componente que recebe as requisições.

Qual foi a contribuição da Anthropic e do Google

O Apache creditou a descoberta da vulnerabilidade ao Anthropic OSS Scanner e a Anthony Weems e Simon Scannell, do Google Cloud Vulnerability Research. O relato da Anthropic chegou em 26 de outubro; o do Google, em 3 de novembro. Essas informações confirmam a participação do scanner da Anthropic na descoberta de uma falha grave em um software de servidor amplamente utilizado.

Mas a expressão “a IA encontrou uma vulnerabilidade” esconde um detalhe importante: o registro oficial cita um scanner específico e pesquisadores específicos. Ele não permite concluir que as duas descobertas foram totalmente autônomas nem que pessoas deixaram de ser necessárias para verificar os resultados. Para desenvolvedores de ferramentas de segurança, o resultado em si chama a atenção: a busca automatizada encontrou uma falha na interação entre threads capaz de levar à execução de código.

A dimensão do problema exige uma leitura cuidadosa. Segundo a Wiz, 64% dos ambientes de nuvem observados contêm recursos com versões vulneráveis, e 51% têm instâncias acessíveis publicamente. A empresa ressalta que essas estimativas não levam a configuração em conta. Portanto, o número de instalações ainda não indica quantos servidores podem realmente ser atacados via HTTP/2.

Quando a Wiz publicou seu relatório em 11 de novembro, não havia exploit público nem relatos de exploração. Esse é um retrato de uma data específica: não garante a ausência de ataques nem descreve a situação uma semana depois.

O que sua equipe deve verificar

Comece pelos servidores expostos à internet: identifique a versão do Apache, a presença do mod_http2 e o uso efetivo de HTTP/2. Se houver outro proxy à frente da aplicação, descubra qual protocolo chega ao Apache. A simples presença de um serviço intermediário não responde a essa pergunta.

Em seguida, instale a correção do Apache 2.4.71 ou a atualização de pacote correspondente fornecida pelo fornecedor do seu sistema. Para pacotes com correções aplicadas a versões anteriores, siga o aviso do fornecedor: o número da versão base, por si só, pode não indicar a presença do patch. Após a atualização, verifique a inicialização do servidor, a configuração e os principais fluxos de uso.

Se for necessário adiar a atualização, a Wiz sugere desativar temporariamente o HTTP/2. Depois da alteração, confirme que os clientes conseguem acessar o serviço e que o protocolo afetado está de fato desativado. Essa é uma medida temporária até a instalação da correção.

Para responsáveis por produto e fundadores, a tarefa é bastante prática: dar à equipe tempo para atualizar e obter a confirmação de quais servidores foram verificados. Esse resultado é mais útil do que uma declaração genérica de que “a segurança está sob controle”.