Falha crítica no Apache (CVE-2026-119618): seu site está em risco?

Talvez. A falha CVE-2026-119618 não está no WordPress, e sim no Apache HTTP Server, o programa que entrega as páginas em boa parte das hospedagens. Seu site corre risco se o servidor usa Apache 2.4.55 a 2.4.70 com HTTP/2 ativado. Se você está em hospedagem compartilhada, a correção depende da empresa de hospedagem: mande hoje a mensagem pronta que está mais abaixo. Se você tem VPS própria, atualize o Apache para a 2.4.71 (ou para o pacote corrigido da sua distribuição) agora.

A Apache classificou a falha como crítica, e a Red Hat atribuiu nota 9,8 de 10 no CVSS, a escala padrão de gravidade. É o tipo de atualização que não dá para deixar para o mês que vem.

O que aconteceu, sem tecnês

Em 11 de novembro de 2026, a Apache Software Foundation lançou o Apache HTTP Server 2.4.71, que corrige três vulnerabilidades. A mais grave é a CVE-2026-119618, uma falha no mod_http2, o módulo que faz o Apache falar HTTP/2 (a versão mais moderna do protocolo que o navegador usa para carregar o site).

Tecnicamente, é uma condição de corrida (race condition) na função assign_headers(): duas partes do programa mexem na mesma memória ao mesmo tempo, sem a sincronização correta, e isso corrompe a memória do servidor. Segundo os comunicados, um atacante consegue explorar isso sem precisar de login e chegar à execução remota de código (RCE, na sigla em inglês).

Na prática, execução remota de código significa que alguém de fora pode rodar comandos no seu servidor como se estivesse sentado na frente dele. A partir daí, dá para:

• instalar malware e backdoors (portas dos fundos para voltar depois);
• injetar redirecionamentos para sites de apostas, farmácia ou golpes;
• roubar dados de clientes, formulários, pedidos e senhas do banco de dados;
• usar seu servidor para mandar spam ou atacar outros sites, o que pode levar à suspensão da hospedagem.

A falha foi relatada pelo OSS Scanner da Anthropic e, de forma independente, por Anthony Weems e Simon Scannell, da equipe de pesquisa de vulnerabilidades do Google Cloud. Os detalhes estão no comunicado oficial da Apache e na cobertura da SecurityWeek.

Atenção até 11 de novembro, a falha não aparecia no catálogo KEV da CISA, que lista vulnerabilidades com exploração confirmada. Ou seja, não havia ataques reais conhecidos. Isso costuma mudar rápido depois que a correção sai, porque atacantes comparam a versão antiga com a nova para descobrir como explorar. A janela para atualizar com calma é agora.

As outras duas falhas corrigidas na 2.4.71

Quem também usa o módulo mod_h2 avulso, baixado do GitHub do projeto, está afetado nas versões 2.0.8 a 2.0.42.

Meu site está afetado?

Depende de onde e como o site está hospedado. Use a tabela como ponto de partida:

Sobre a CDN: ter Cloudflare na frente não corrige o Apache do seu servidor. Dependendo da configuração, a CDN pode até falar com o servidor de origem em HTTP/1.1, mas isso não é garantido, e se o endereço IP do servidor for acessível diretamente, um atacante pode pular a CDN. Não use a CDN como desculpa para não atualizar.

Como descobrir qual servidor e qual versão você usa

1. Olhe o cabeçalho Server da resposta. No terminal:

curl -sI https://seusite.com.br | grep -i '^server'

Se aparecer algo como Server: Apache/2.4.62, você tem a versão. Muitas hospedagens escondem esse dado e mostram só Apache, ou o nome da CDN (cloudflare). Nesse caso, a resposta não é conclusiva.

2. Veja no painel da hospedagem. No cPanel, a versão do Apache costuma aparecer na barra lateral de "Informações do servidor" ou "Server Information". Outros painéis mostram em "Detalhes do plano" ou similar. Se não achar, pergunte ao suporte.

3. Em VPS, pergunte ao próprio Apache. Conectado por SSH:

apachectl -v
# ou, em distribuições da família Red Hat:
httpd -v

4. Confira se o HTTP/2 está ativo. A falha só afeta quem tem HTTP/2 ligado. Duas formas de checar:

• No navegador, abra o site, aperte F12, vá na aba Rede (Network), recarregue a página e ative a coluna Protocolo. Se aparecer h2, o site responde em HTTP/2.
• No terminal:

curl -sI --http2 https://seusite.com.br | head -1

Se a primeira linha começar com HTTP/2, o HTTP/2 está ativo. Lembre que, se houver uma CDN na frente, você está vendo o protocolo da CDN, não necessariamente o do seu servidor.

Dica atenção ao número da versão em distribuições Linux. Debian, Ubuntu, Red Hat e outras costumam corrigir falhas sem mudar o número principal, aplicando o patch na versão que já usam. Então um 2.4.62 de distribuição pode já estar corrigido. Quem confirma é o aviso de segurança da própria distribuição ou a hospedagem.

Hospedagem compartilhada: o que pedir para a hospedagem

Em hospedagem compartilhada, você não tem acesso para atualizar o Apache. Quem faz isso é a empresa. Hospedagens sérias costumam aplicar correções críticas rápido, mas vale perguntar por escrito, até para ter registro. Copie e envie pelo chamado ou e-mail do suporte:

Olá, equipe de suporte.

Meu site [seusite.com.br] está hospedado na conta [nome ou ID da conta].

Em 11/11/2026 a Apache publicou a versão 2.4.71 do Apache HTTP Server,
corrigindo a falha crítica CVE-2026-119618 (mod_http2, execução remota
de código, versões 2.4.55 a 2.4.70 com HTTP/2 ativo).

Gostaria de confirmar:
1. O servidor onde meu site está usa Apache? Qual versão?
2. Se usa, o servidor já foi atualizado para a 2.4.71 ou para o pacote
   corrigido da distribuição? Se não, qual a previsão?
3. Até a correção, vocês aplicaram alguma mitigação, como desativar o
   HTTP/2?

Obrigado.

Se a resposta for vaga ("nossos servidores são seguros") ou demorar dias, considere isso um sinal sobre a hospedagem. Uma falha crítica com correção pública merece resposta objetiva.

VPS ou servidor próprio: como corrigir

Se você administra o servidor, atualize pelo gerenciador de pacotes da sua distribuição, e não compilando o Apache na mão. As distribuições publicam seus próprios pacotes corrigidos (o Debian unstable, por exemplo, já recebeu o 2.4.71-1). Compilar por conta própria cria um Apache paralelo que ninguém vai lembrar de atualizar na próxima falha.

Antes de qualquer coisa, faça backup da configuração (/etc/apache2 ou /etc/httpd) e, se possível, um snapshot da VPS no painel do provedor.

Debian e Ubuntu:

sudo apt update
sudo apt install --only-upgrade apache2
sudo systemctl restart apache2

RHEL, AlmaLinux, Rocky, Fedora:

sudo dnf upgrade httpd mod_http2
sudo systemctl restart httpd

Se o comando não trouxer atualização, o pacote corrigido da sua distribuição pode ainda não ter saído. Acompanhe o aviso de segurança da distribuição e use a mitigação abaixo enquanto isso.

Mitigação temporária: desligar o HTTP/2

O comunicado da Apache não lista solução alternativa. Como medida temporária, a Wiz recomenda remover h2 e h2c da diretiva Protocols, deixando só HTTP/1.1. Procure a diretiva na configuração:

grep -Rni "^\s*Protocols" /etc/apache2/ /etc/httpd/ 2>/dev/null

E troque, em cada ocorrência, algo como Protocols h2 h2c http/1.1 por:

Protocols http/1.1

Depois, teste a configuração e reinicie:

sudo apachectl configtest
sudo systemctl restart apache2   # ou httpd

O site continua funcionando normalmente em HTTP/1.1, só um pouco menos eficiente em páginas com muitos arquivos. Quando o pacote corrigido estiver instalado, volte a configuração ao que era.

Confirme que deu certo

Depois de atualizar, rode de novo apachectl -v (ou httpd -v) e confira a versão ou o pacote instalado (apt policy apache2 no Debian/Ubuntu, rpm -q httpd mod_http2 na família Red Hat) contra o aviso de segurança da sua distribuição. Se aplicou a mitigação, teste com curl -sI --http2 direto no servidor: a resposta deve vir em HTTP/1.1.

Acha que já foi invadido?

Atualizar fecha a porta, mas não expulsa quem já entrou. Se o servidor ficou exposto e você notar algo estranho, investigue antes de seguir a vida. Sinais comuns:

• redirecionamento para sites de apostas, farmácia ou golpes, às vezes só no celular ou só para quem vem do Google;
• páginas em japonês ou de spam aparecendo nos resultados do Google;
• administradores no WordPress que você não criou;
• arquivos PHP novos e estranhos em pastas como wp-content/uploads;
• uso de CPU alto sem motivo, ou e-mail da hospedagem falando em spam ou malware;
• aviso de "site perigoso" no Chrome.

Um primeiro passo rápido é rodar o verificador gratuito de site invadido, que analisa o site de fora, como um visitante veria. Ele não enxerga tudo o que está no servidor, mas pega os sinais mais visíveis. Para entender os sintomas com calma, veja como saber se seu site foi hackeado, e se a resposta for sim, siga o passo a passo das primeiras horas depois de uma invasão.

Com o Apache corrigido, aproveite para revisar o resto: plugins, senhas, 2FA e backups. O checklist de segurança para WordPress cobre os pontos que mais fazem diferença.

Precisa de ajuda?

Se o site já mostra sinais de invasão, o Mobgeek Studio faz a limpeza de site WordPress invadido: remoção de malware e backdoors, atualizações, blindagem e relatório de como o invasor entrou. A partir de R$ 790 por site, com início em até 24h e 30 dias de garantia contra reinfecção. Se você tem VPS e prefere que alguém confira a versão do Apache, aplique a correção e revise a segurança do servidor, peça um orçamento.