Falha na atualização do WordPress sob ataque: quase 63.000 tentativas de exploração em 24 horas

Os atacantes não perderam tempo. Apenas dois dias depois do lançamento do WordPress 7.1.4, a 28 de outubro de 2026, as tentativas de explorar a vulnerabilidade de gravidade elevada corrigida por essa versão já se contavam às dezenas de milhares por dia. A falha permite a execução remota de código sem autenticação em sites que correm o WordPress Core da versão 4.7 à 7.1.3 e tem uma pontuação CVSS de 8,1. À data desta publicação ainda não lhe foi atribuído um identificador CVE.

O que aconteceu

A fragilidade está num sítio pouco óbvio: a forma como o WordPress descompacta uma atualização completa do núcleo. Quando um site instala uma versão completa (e não uma atualização parcial), os novos ficheiros são extraídos para uma pasta temporária de preparação em wp-content/upgrade antes de serem movidos para o destino final. Dois pormenores transformam este passo de rotina numa superfície de ataque:

• o caminho da pasta temporária é previsível e, em muitas configurações de alojamento, está acessível a partir da web e executa PHP;
• a cópia preparada inclui o instalador do WordPress, incluindo o setup-config.php.

Um atacante não autenticado que peça o instalador preparado no momento exato consegue usá-lo contra a cópia meio instalada e chegar à execução de código PHP no servidor. Trata-se de uma condição de corrida (race condition): em laboratório a janela dura apenas alguns segundos e fecha-se quando o WordPress termina a atualização e apaga os ficheiros temporários.

Para o ataque ter sucesso, todas estas condições têm de se verificar em simultâneo:

1. está a ser aplicada uma atualização completa que contém os ficheiros do instalador;
2. a árvore temporária está publicamente acessível pela web e o PHP é executado a partir dela;
3. o atacante conhece ou adivinha o caminho da pasta temporária;
4. o atacante conclui a sequência antes da limpeza.

Porque é importante

Uma janela de poucos segundos parece impossível de explorar. O tráfego diz o contrário. A telemetria de firewalls para WordPress registou perto de 63.000 pedidos bloqueados dirigidos a esta falha num único período de 24 horas. Duas das maiores fontes martelaram pequenos grupos de sites durante cerca de catorze horas e meia cada uma, consultando repetidamente o caminho do instalador na esperança de apanhar uma atualização a decorrer. Outras dispersaram-se, testando muitas variantes de pasta temporária e de nome de versão até encontrar a certa.

Nem todos os pedidos atingiram o caminho vulnerável exato, mas a sondagem persistente e os testes ajustados à estrutura de ficheiros mostram que os atacantes perceberam rapidamente a condição de corrida e construíram ferramentas para a explorar. Como o gatilho é o próprio processo de atualização do site, os mais expostos são precisamente os sites que fazem o que devem: atualizar-se. Os alojados em hosting partilhado, onde a pasta de atualização é frequentemente legível pela web, são o alvo mais natural.

O que fazer

• Atualize já para o WordPress 7.1.4. Todas as versões da 4.7 à 7.1.3 são afetadas. Confirme a versão em cada site, não apenas nos que se lembra.
• Verifique os registos do servidor web à procura de pedidos a ficheiros PHP em wp-content/upgrade, sobretudo acessos repetidos ao setup-config.php ou a subpastas com nome de versão. A sondagem repetida desse caminho a partir de uma única origem é um sinal forte.
• Procure persistência. Reveja as contas de administrador, os plugins instalados e os plugins must-use, e procure ficheiros PHP que não colocou lá, em particular nas pastas de uploads e de temas.
• Reforce a pasta temporária. Onde o alojamento o permitir, negue o acesso web a wp-content/upgrade ou desative a execução de PHP dentro dela. Isto também atenua futuras variantes da mesma ideia.
• Continue a aplicar atualizações. A falha só fica exposta enquanto decorre uma atualização, pelo que a solução é estar numa versão em que o passo de preparação é seguro, e não deixar de atualizar.

Falhas como esta passam despercebidas precisamente porque o componente vulnerável não é um plugin nem um tema, mas alguns segundos dentro de um processo de rotina. Manter um inventário rigoroso da versão do WordPress que cada site corre e ser alertado no dia em que uma versão fica para trás é o tipo de problema que o nosso serviço de análise de vulnerabilidades resolve: assinala versões do núcleo desatualizadas em toda a infraestrutura, para que um atraso de dois dias não se transforme num de dois meses.