O WordPress 7.1.4 foi lançado em 28 de outubro de 2026 trazendo correções para 22 vulnerabilidades de segurança identificadas no núcleo da plataforma. Entre elas, destaca-se uma falha classificada como a mais grave: uma condição de corrida não autenticada no processo de atualização do Core, capaz de permitir execução remota de código. De acordo com monitoramento de ameaças, agentes maliciosos já começaram a tentar explorar essa brecha logo após o anúncio da atualização, o que reforça a urgência de os administradores de sites confirmarem se seus ambientes já estão rodando a versão 7.1.4 ou a atualização de segurança correspondente à sua respectiva branch.
Assinantes do Wordfence Premium, Care e Response receberam uma nova regra de firewall em 28 de outubro, cerca de três horas após o lançamento oficial. Já os usuários da versão gratuita do Wordfence só terão acesso à mesma proteção depois do prazo padrão de 30 dias, previsto para 27 de novembro de 2026.
O que motivou a atualização de segurança do WordPress 7.1.4
A nova versão corrige um conjunto amplo de problemas no núcleo do WordPress, incluindo cross-site scripting persistente, negação de serviço, exposição de informações, falhas de autorização e, principalmente, a condição de corrida que pode resultar em execução remota de código.
Essa vulnerabilidade de execução remota chama atenção porque não exige nenhuma conta cadastrada no site para ser explorada. Por outro lado, para que o ataque seja bem-sucedido, é necessário acertar uma janela de tempo extremamente curta durante o processo de descompactação de uma atualização completa do Core. Em ambientes de laboratório, essa janela costumava durar apenas segundos. Ainda assim, atacantes têm feito requisições repetidas a caminhos vulneráveis na tentativa de capturar esse intervalo.
Na maioria dos casos, os sites WordPress recebem essa atualização automaticamente em segundo plano. Mesmo assim, recomenda-se fortemente verificar o status da atualização em vez de simplesmente presumir que ela foi concluída. Basta acessar Painel > Atualizações e confirmar se o site está rodando o WordPress 7.1.4 ou a versão corrigida correspondente à sua branch.
Proteção de firewall contra a falha do WordPress 7.1.4
A equipe de resposta a ameaças responsável pelo Wordfence implementou uma nova regra de bloqueio em 28 de outubro de 2026, às 20h30 UTC, aproximadamente três horas depois do anúncio oficial da atualização de segurança. Assinantes Premium, Care e Response receberam a proteção de forma imediata, enquanto os usuários da versão gratuita só terão acesso em 27 de novembro de 2026, após o período padrão de carência de 30 dias.
Esse exploit faz uma requisição direta a um arquivo PHP previamente estagiado, sem antes carregar o WordPress. Por isso, é importante que os sites verifiquem se o firewall está otimizado com Proteção Estendida, recurso que permite que a barreira de segurança atue antes mesmo que requisições diretas a arquivos PHP alcancem o destino solicitado. Receber a regra de proteção não substitui, porém, a instalação da atualização de segurança.
Como funciona a brecha de execução remota não autenticada
A vulnerabilidade foi identificada pelo pesquisador Umut Bayram e afeta o WordPress Core nas versões 4.7.0 a 7.1.3, recebendo classificação CVSS de 8,1 (alta gravidade). O problema ocorre porque, durante uma atualização do Core que utiliza um pacote completo, as versões afetadas descompactam os novos arquivos em um diretório previsível dentro de wp-content/upgrade. Essa cópia temporária inclui o instalador do WordPress e, como o diretório de preparação costuma ficar acessível via web em muitos servidores, um atacante não autenticado que faça a requisição no momento exato pode interagir com a cópia estagiada e avançar até a execução de código PHP.
A gravidade da falha está ligada ao impacto potencial: uma exploração bem-sucedida pode conceder ao invasor a capacidade de executar código no servidor. No entanto, a complexidade do ataque é considerada alta, já que o atacante precisa de uma atualização completa com os arquivos do instalador, acesso público via web e PHP à árvore de preparação, um caminho de staging previsível ou descoberto, além de tempo suficiente para concluir o ataque antes que o WordPress remova os arquivos temporários.
Acima de tudo, o invasor precisa vencer essa corrida contra o tempo. Em ambientes de laboratório, o diretório de preparação vulnerável costumava permanecer disponível por apenas alguns segundos — o que torna uma requisição isolada pouco eficaz, mas abre espaço para que a varredura automatizada e repetida aumente as chances de sucesso do atacante.
Para resolver o problema, o WordPress 7.1.4 randomizou o diretório de preparação, adicionou uma proteção de índice e passou a impedir a promoção insegura de dados de configuração estagiados. A correção também foi retroportada para as branches afetadas, alcançando versões a partir do WordPress 4.7.
Exploração ativa já em andamento
Dados de telemetria indicam que agentes maliciosos já estão tentando explorar ativamente essa vulnerabilidade do WordPress 7.1.4. A primeira correspondência com a nova regra de firewall surgiu apenas nove minutos após sua implementação. Nas primeiras 21 horas, foram registradas mais de 18.500 requisições direcionadas a caminhos de instalador staged-setup-config.php.
Duas das maiores origens de tráfego malicioso fizeram varreduras repetidas em pequenos grupos de sites durante aproximadamente 14,5 horas, comportamento compatível com a tentativa de capturar a breve janela de atualização. Outras origens testaram diversas variações de diretórios de preparação e nomes de versão. Embora nem todas as requisições tenham utilizado exatamente o caminho vulnerável, a varredura contínua e os testes precisos de estrutura mostram que os atacantes compreenderam rapidamente a lógica da condição de corrida e passaram a mirar nela.
Outras correções incluídas na atualização
A documentação detalhada do lançamento contabiliza 22 vulnerabilidades corrigidas. Além da falha de execução remota durante a janela de atualização, a versão também resolve:
- Múltiplas vulnerabilidades de cross-site scripting persistente envolvendo delimitadores de blocos, o bloco de Categorias, rótulos de Paginação de Comentários e Navegação de Posts, atualização seletiva do Customizer, solicitações de exclusão de dados pessoais, nomes de usuário especialmente criados e o tratamento dos blocos de Imagem e Playlist;
- Diversos problemas na Interactivity API, incluindo vínculos inseguros de URL, manipuladores de eventos, propriedades internas e objetos; poluição de protótipo; sombreamento de dados em Script Module; tratamento de arquivos de texto enviados no Interactivity Router; e uma condição persistente de negação de serviço;
- Uma falha de exposição de informações não autenticada que poderia revelar changesets não publicados do Customizer;
- Uma fragilidade de autorização na API REST de Notas, que afeta papéis personalizados com permissão para moderar comentários, mas sem permissão para editar o post ao qual a nota está vinculada;
- Uma atualização dos certificados raiz incluídos no pacote, em resposta à revogação da eMudhra.
Vale destacar que muitas das demais vulnerabilidades exigem uma conta autenticada com papel de Colaborador, Autor ou Editor, e algumas delas também dependem de uma vítima visualizar conteúdo controlado pelo atacante. Esses pré-requisitos reduzem a exposição em comparação com a falha de execução remota não autenticada, mas não tornam os problemas inofensivos: o cross-site scripting persistente, por exemplo, pode levar à tomada de contas ou a alterações no site quando um usuário com privilégios elevados acessa uma página maliciosa.
Recomendações para administradores de sites WordPress
Diante do cenário de exploração ativa, algumas medidas são essenciais para reduzir os riscos:
- Confirmar que o WordPress foi de fato atualizado, instalando a versão 7.1.4 ou a correção de segurança correspondente à branch utilizada. Sites que ainda rodam o WordPress 4.6 ou versões anteriores não recebem mais atualizações de segurança e precisam migrar para uma versão suportada;
- Verificar se o firewall está ativado e devidamente otimizado, já que a Proteção Estendida é especialmente importante para a vulnerabilidade mais grave desta atualização, uma vez que a requisição maliciosa vai direto a um arquivo PHP sem passar pelo carregamento do WordPress;
- Não depender apenas do firewall em substituição à atualização: a proteção reduz a exposição durante o processo, mas é a instalação da versão corrigida do Core que efetivamente elimina o comportamento vulnerável;
- Revisar qualquer atividade suspeita relacionada ao diretório de atualização caso o site tenha permanecido sem correção por algum tempo, já que isso pode indicar tentativas de exploração durante o período de exposição.
Em resumo, a combinação entre a gravidade potencial da falha e os indícios concretos de exploração ativa torna a atualização para o WordPress 7.1.4 uma prioridade imediata para qualquer administrador de site baseado na plataforma. Mesmo com a complexidade técnica envolvida na exploração da brecha, a velocidade com que agentes maliciosos passaram a testar o problema demonstra que a janela de segurança para agir é curta — e que medidas preventivas, como firewalls bem configurados, funcionam apenas como camada complementar, nunca como substituto da correção oficial.
Com informações de wordfence.com.
