Foi corrigida uma vulnerabilidade de alta gravidade no próprio mecanismo de atualização do WordPress, e os atacantes começaram a tentar explorá-la poucos minutos depois de a correção sair. A falha foi resolvida na versão 7.1.4, publicada a 28 de outubro. Um atacante sem qualquer credencial pode executar código no servidor se conseguir chegar, no momento certo, aos ficheiros temporários que a plataforma descompacta durante uma atualização completa do núcleo. Segundo a SecurityWeek, a Defiant (a empresa que desenvolve o Wordfence) alertou que os atacantes começaram a explorar esta nova vulnerabilidade de alta gravidade poucas horas depois de as correções começarem a ser distribuídas.
Resposta rápida: O WordPress 7.1.4 corrige uma condição de corrida (race condition) no processo de atualização do núcleo. Esta falha permite executar código remotamente sem autenticação e afeta as versões 4.7 a 7.1.3. O Wordfence já regista tentativas de exploração, mas até agora não foram confirmados sites comprometidos. Atualize já para a 7.1.4 ou para a versão corrigida do seu ramo, bloqueie o acesso web a wp-content/upgrade/ e procure ficheiros PHP ou contas de administrador que não reconheça.
Uma janela de segundos no pior momento possível
O problema está no momento em que o WordPress se atualiza a si próprio. Quando é feita uma atualização do núcleo com o pacote completo, as versões afetadas descompactam os novos ficheiros num diretório previsível dentro de wp-content/upgrade, e esses ficheiros temporários incluem o instalador do WordPress. Até à versão 7.1.4, a pasta de extração tinha o nome do pacote, o que tornava o caminho previsível.
Se o servidor permitir acesso público e execução de PHP nessa pasta temporária, o atacante pode pedir diretamente o instalador que lá ficou. Quem lhe chegar no momento certo pode correr a rotina de configuração contra uma base de dados controlada por si, o que abre caminho à execução remota de código. O tempo disponível é muito curto: em ambiente de laboratório, o diretório vulnerável costumava ficar disponível apenas durante alguns segundos.
Há ainda outro pormenor que agrava o risco. O pedido do atacante vai diretamente à cópia descompactada, pelo que nem o WordPress do próprio site nem qualquer plugin de segurança que corra dentro dele chegam a vê-lo. Por isso, a proteção tem de ser feita ao nível do servidor ou de uma firewall aplicacional externa.
Versões afetadas e gravidade
| Elemento | Detalhe |
|---|---|
| Componente | Processo de atualização do núcleo (wp-content/upgrade/) |
| Tipo de falha | Condição de corrida que leva a execução remota de código (RCE) |
| Versões afetadas | WordPress 4.7 a 7.1.3 |
| Versões corrigidas | 7.1.4 e versões corrigidas dos ramos anteriores (por exemplo 7.0.8, 6.9.11 e até 4.7.39) |
| Identificador CVE | Ainda não atribuído |
| CVSS | 8.1 segundo o Wordfence; a Patchstack aponta para uma pontuação de 9 |
| Autenticação necessária | Nenhuma |
| Complexidade | Alta (é preciso acertar numa janela de segundos) |
| Sem correção | WordPress 4.6 e anteriores |
O Wordfence diz que a falha afeta o WordPress da versão 4.7 à 7.1.3 e atribui-lhe 8.1 na escala CVSS. Não é preciso iniciar sessão, mas a complexidade do ataque é alta, porque o atacante tem de ganhar uma corrida contra o próprio sistema. Ainda não foi atribuído um identificador CVE à vulnerabilidade. O WordPress não é uma autoridade de numeração CVE (CNA), o que ajuda a explicar o atraso. A falha foi reportada por Umut Bayram. As versões 4.6 e anteriores não recebem qualquer correção.
O que muda com a correção
A correção tem três partes. Segundo a análise técnica da Patchstack, a versão 7.1.4 acrescenta 16 caracteres aleatórios ao nome da pasta, volta a criar o ficheiro index.php e deixa de o apagar. Há também uma alteração que o anúncio oficial não refere: no ficheiro update-core.php, o wp-config.php passa a constar da lista de ficheiros que nunca são copiados para fora do diretório de trabalho.
Com o nome aleatório, o atacante já não consegue adivinhar onde está o instalador. O ficheiro index.php impede que a pasta seja listada, e a exclusão do wp-config.php protege a configuração que acompanha a atualização.
Cronologia da exploração
| Data / momento | Acontecimento |
|---|---|
| 28 de outubro de 2026 | Publicação do WordPress 7.1.4, com versões corrigidas para os ramos suportados até ao 4.7.39 |
| 28 de outubro, cerca das 20h30 UTC | O Wordfence ativa uma regra de firewall dirigida à falha |
| Nove minutos depois | A regra deteta a primeira tentativa de exploração |
| Primeiras 21 horas | São registados mais de 18 500 pedidos a caminhos do instalador temporário |
| 30 de outubro | Continua sem CVE atribuído e sem compromissos confirmados publicamente |
O Wordfence ativou a regra de firewall por volta das 20h30 UTC de 28 de outubro, e o primeiro pedido correspondente chegou nove minutos depois. Nas primeiras 21 horas após a ativação da regra, a empresa registou mais de 18 500 pedidos a caminhos do instalador temporário. O padrão de tráfego mostra paciência: duas das maiores origens consultaram repetidamente pequenos grupos de sites durante cerca de 14,5 horas, um comportamento compatível com a tentativa de apanhar a breve janela de atualização.
É preciso ler estes números com cuidado. O que estas observações provam é que há tentativas de exploração ativas, não que haja sites efetivamente comprometidos. Ainda assim, nem todos os pedidos usaram o caminho vulnerável exato, mas a consulta persistente e as sondagens com a estrutura correta mostram que os atacantes perceberam depressa a condição de corrida e passaram a explorá-la.
Sinais de comprometimento a verificar
Não foram publicados endereços IP nem ficheiros maliciosos específicos. No entanto, para os sites que ficaram sem atualização, o Wordfence aconselha a procurar pedidos inesperados a ficheiros PHP dentro de wp-content/upgrade, contas de administrador desconhecidas, plugins que não foram instalados pelos responsáveis ou ficheiros PHP que ninguém lá colocou.
| Onde procurar | Indicador |
|---|---|
| Registos de acesso do servidor web | Pedidos a ficheiros .php dentro de wp-content/upgrade/ |
| Utilizadores do WordPress | Contas de administrador criadas recentemente sem justificação |
| Plugins | Plugins instalados ou ativados sem intervenção da equipa |
| Sistema de ficheiros | Ficheiros PHP desconhecidos, sobretudo em pastas de atualização ou de carregamentos |
| Núcleo | Ficheiros do núcleo alterados em relação à versão oficial |
Passos concretos de mitigação
- Atualizar já para o WordPress 7.1.4 ou para a versão corrigida do ramo que usa. A versão 7.1.4 está disponível no painel, em Atualizações, ou em WordPress.org, e os sites com atualizações em segundo plano recebem-na sem intervenção.
- Confirmar a versão instalada. Verifique o número da versão em vez de partir do princípio de que a atualização automática funcionou.
- Bloquear
wp-content/upgrade/no servidor. A Patchstack recomenda bloquear o acesso web a esta pasta ao nível do servidor e confirmar que o seu conteúdo não pode ser listado. Desativar a execução de PHP nessa pasta reforça a proteção. - Limpar restos de atualizações. Apague as pastas que uma atualização falhada possa ter deixado para trás.
- Usar proteção externa à aplicação. Os utilizadores do Wordfence devem ativar a Extended Protection, porque a exploração pede diretamente ficheiros PHP sem passar primeiro pelo WordPress.
Uma atualização com 22 correções
A condição de corrida é a falha mais grave, mas não é a única. O WordPress 7.1.4 saiu a 28 de outubro de 2026 com correções para aquilo que o projeto conta como 22 vulnerabilidades, distribuídas por 17 avisos. Segundo a Patchstack, quase todas exigem uma conta no site para serem exploradas, normalmente com o perfil de Colaborador. Entre elas estão vários casos de cross-site scripting (XSS) armazenado na Interactivity API, no Personalizador, no bloco de Categorias e noutros blocos, uma negação de serviço armazenada na Interactivity API e uma falha que deixa utilizadores não autenticados descobrir conjuntos de alterações do Personalizador ainda por publicar.
O ritmo de correções tem sido intenso. É a sétima versão de segurança do núcleo desde meados de julho. Há cerca de um mês, a SecurityWeek noticiou que a CVE-2026-87902, uma falha de path traversal que pode levar a RCE, foi corrigida a 22 de setembro na versão 7.1.2 e começou também a ser explorada poucas horas depois de ser divulgada.
Porque é que isto importa em Portugal
Muitos sites institucionais, lojas online e portais de PME portuguesas usam WordPress, muitas vezes com alojamento partilhado e sem uma equipa técnica dedicada. Neste caso, a falha está no mecanismo que devia proteger o site: o momento da atualização. As organizações que adiam atualizações ou não controlam a configuração do servidor ficam mais expostas.
Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a gestão de vulnerabilidades e a aplicação rápida de correções fazem parte das medidas de gestão de risco exigidas. Os incidentes significativos têm de ser notificados ao CNCS/CERT.PT. Se um site comprometido tratar dados pessoais, como formulários de contacto, clientes ou encomendas, o RGPD obriga a avaliar a violação e, quando aplicável, a notificá-la à CNPD no prazo de 72 horas. Atualizar hoje sai muito mais barato do que gerir um incidente amanhã.
Perguntas frequentes
Que versões do WordPress estão vulneráveis?
As versões 4.7 a 7.1.3. A correção está na 7.1.4 e nas versões corrigidas dos ramos anteriores, até à 4.7.39. As versões 4.6 e anteriores não recebem correção e devem ser atualizadas para um ramo suportado.
É preciso ter uma conta no site para explorar a falha?
Não. A falha pode ser explorada sem autenticação, mas o atacante tem de acertar numa janela de poucos segundos durante uma atualização completa do núcleo. Além disso, a pasta wp-content/upgrade/ tem de estar acessível pela web e permitir a execução de PHP.
Um plugin de segurança protege o meu site?
Não totalmente. O pedido malicioso vai diretamente à cópia temporária do WordPress, por isso os plugins que correm dentro do site não o veem. A proteção eficaz é atualizar e bloquear a pasta de atualizações no servidor ou numa firewall aplicacional externa.
Como sei se o meu site foi atacado?
Procure nos registos do servidor pedidos a ficheiros PHP dentro de wp-content/upgrade/. Verifique também se há contas de administrador desconhecidas, plugins que não instalou e ficheiros PHP estranhos. Se encontrar algum destes sinais, trate a situação como um incidente e avalie as obrigações de notificação.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pelo Wordfence (Defiant), pela Patchstack, pelo projeto WordPress e pela SecurityWeek.