Falha do WordPress já está a ser explorada: o que fazer no site da sua empresa

A agência norte-americana de cibersegurança, a CISA, confirmou a 3 de novembro de 2026 que há ataques reais a uma falha do núcleo do WordPress. A vulnerabilidade, agora identificada como CVE-2026-119977, foi corrigida a 28 de outubro na versão 7.1.4 e afeta todas as versões entre a 4.7 e a 7.1.3. A CISA acrescentou-a ao seu catálogo de vulnerabilidades exploradas e deu às agências federais dos EUA até 6 de novembro para a corrigirem.

Quando falámos desta atualização, em «WordPress 7.1.4 corrige 22 falhas de segurança», esta falha ainda não tinha número CVE e a Patchstack considerava-a difícil de explorar na prática. Uma semana depois, o cenário mudou. Se o site, a loja ou o blogue da sua empresa usa WordPress, explicamos o que se sabe e o que deve verificar hoje.

O que é a falha

Segundo a descrição da CISA, trata-se de uma condição de corrida do tipo «verificação/utilização» (TOCTOU) que pode permitir a atacantes sem conta no site executar código no servidor durante a janela de atualização. A causa está nos caminhos temporários, previsíveis e acessíveis pela web, que o WordPress usa quando instala uma atualização completa do núcleo.

Dito de forma simples: durante os segundos em que o WordPress está a atualizar-se, ficam no servidor ficheiros temporários num local que é possível adivinhar. Se um atacante chegar a esse local nesse momento, pode conseguir correr o seu próprio código no servidor.

A falha foi comunicada ao WordPress pelo investigador Umut Bayram, da Picus Security, segundo o BleepingComputer. Tem uma pontuação CVSS de 8,1 em 10, o que a classifica como de gravidade alta, de acordo com o alerta do NHS England e com o The Hacker News.

O que se sabe sobre os ataques

A CISA não divulgou pormenores sobre quem está a atacar nem sobre as vítimas. No catálogo, indica que não se sabe se a falha está a ser usada em campanhas de ransomware. Os números públicos vêm de empresas de segurança:

• A Wordfence, especializada em segurança WordPress, registou mais de 18.500 pedidos dirigidos a caminhos do instalador temporário (setup-config.php) nas primeiras 21 horas depois de a falha ser tornada pública, segundo o The Hacker News.
• Numa atualização do aviso, a Wordfence disse ter bloqueado 13.095 ataques a esta falha em 24 horas. O The Hacker News, na sua publicação de 4 de novembro, indica 12.632 ataques bloqueados nas 24 horas anteriores.
• Segundo o mesmo site, a empresa Previdian registou três tentativas de exploração nos seus sensores-armadilha, a 30 de outubro, a partir de um endereço IP localizado no Reino Unido.

Não há dados públicos sobre sites portugueses afetados. O centro de operações de segurança do NHS England considera provável que a exploração continue.

Convém ter presente que estes números são tentativas, não sites comprometidos. Mostram, no entanto, que há quem esteja a procurar ativamente sites WordPress no momento em que se atualizam.

Que versões estão afetadas

Todas as versões do WordPress entre a 4.7 e a 7.1.3. A correção chegou na 7.1.4 e o projeto WordPress, no anúncio oficial, pede que atualize os sites «imediatamente». As correções foram também levadas para os ramos antigos ainda elegíveis, até à série 4.7. A tabela completa de versões corrigidas por ramo está no nosso artigo de 29 de outubro.

O próprio WordPress lembra que só a versão mais recente tem suporte ativo. Se o seu site ainda está num ramo antigo, este é um bom momento para planear a passagem para a 7.1.

Porque é que o momento da atualização importa

Esta falha tem uma particularidade: só pode ser explorada enquanto decorre uma atualização completa do núcleo. Isso tem duas consequências práticas.

Primeiro, um site que nunca se atualiza não fica protegido por isso. Fica apenas exposto a todas as outras falhas conhecidas, incluindo as outras 21 corrigidas na 7.1.4.

Segundo, a própria atualização para a 7.1.4 pode ser o momento de risco. Segundo os testes da Atlas Security que citámos no artigo anterior, a atualização para a 7.1.4 ainda passa pelo código antigo. Por isso, a recomendação da Patchstack era bloquear primeiro o acesso web à pasta de atualizações e só depois atualizar.

O que fazer hoje

1. Confirme a versão. No painel, em Painel → Atualizações, ou no rodapé da área de administração. Deve ver 7.1.4, uma versão posterior, ou a versão corrigida do seu ramo.
2. Confirme que a atualização automática terminou. O NHS England recomenda verificar se as atualizações automáticas foram concluídas com sucesso. Algumas definições no wp-config.php, ou instalações geridas com Git ou Composer, desligam as atualizações automáticas do núcleo.
3. Bloqueie o acesso web à pasta wp-content/upgrade/. Peça ao seu alojamento ou a quem gere o servidor que impeça o acesso pela web a esta pasta e a listagem do seu conteúdo, se ainda não estiver feito.
4. Veja os registos do servidor. Procure pedidos a caminhos dentro de wp-content/upgrade/ ou a ficheiros setup-config.php fora do sítio habitual, sobretudo nas datas em que o site se atualizou desde o fim de outubro.
5. Procure sinais de intrusão. Utilizadores de administração que não reconhece, plugins que não instalou, ficheiros PHP novos em pastas de uploads ou de atualização, e redirecionamentos estranhos. A CISA exige às agências federais uma verificação forense deste tipo, além da correção.
6. Garanta uma cópia de segurança recente e que sabe repô-la, como explicamos em «Cópias de segurança: como saber se o site volta».

Se tem vários sites, comece por aqueles com loja online, área de clientes ou formulários com dados pessoais.

E se encontrar sinais de ataque?

Nesse caso, atualizar já não chega: o atacante pode ter deixado uma porta de entrada no servidor. Siga os passos de «O site foi pirateado: o que fazer nas primeiras horas» e lembre-se de que, se houver dados pessoais envolvidos, pode ter de notificar a CNPD no prazo de 72 horas previsto no RGPD.

Um padrão que se repete

Não é a primeira vez este ano. Em setembro, as primeiras tentativas de ataque à falha corrigida na 7.1.2 surgiram no próprio dia da correção, segundo a Patchstack, como contámos em «WordPress: há uma atualização crítica e já está a ser usada». Em julho, segundo o BleepingComputer, surgiram exploits públicos para a cadeia de falhas conhecida como wp2shell um dia depois de sair a correção.

A lição é a mesma: num site WordPress, a manutenção não pode esperar pelo mês seguinte. Defendemos isso em «WordPress seguro: a manutenção que evita o susto».

Se não tem a certeza de que o seu site está atualizado e protegido, pode começar pela auditoria gratuita da MarcaWeb, que analisa a segurança do site e indica o que corrigir primeiro.