Alerta de segurança no WordPress: adesivos de emergência corrigem uma grave execução remota de código no núcleo

O WordPress publicou patches de emergência em 17 de julho de 2026 para fechar uma vulnerabilidade de execução remota de código que, segundo a descoberta, pode ser ativado com um pedido HTTP anônimo contra uma instalação por defeito sem plugins. Os adesivos aparecem nas versões 6.9.5 e 7.0.2, e a correção também está presente em 7.1 beta2; os ramos afetados foram 6.9.0–6.9.4 e 7.0.0–7.0.1. Porque a falha está no núcleo, um site recém-instalado estava teoricamente em risco.

O achado foi relatado por Adam Kues de Assetnote através do programa HackerOne do WordPress e publicado sob o pseudônimo wp2shell; a assinatura decidiu não revelar os detalhes técnicos completos e, em seu lugar, disponibilizou um verificador público em wp2shell.com para que administradores verifiquem suas instâncias. WordPress descreve o problema como uma combinação de confusão na rota por lotes da API REST e uma injeção SQL que pode resultar em RCE; os arquivos tocados pela correção incluem /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php e /wp- includes/rest- api.php.

Existem dois pontos práticos que os responsáveis por sites devem assumir imediatamente: não confiem em que todos os sites receberam o adesivo automaticamente, e não espere que os scanners baseados em CVE o detectem ainda. O WordPress activou uma atualização forçada através do seu sistema de auto-updates para tentar acelerar a proteção, mas a empresa não esclareceu se essa pulsação atinge instalações que têm atualizações automáticas desativadas. Além disso, como não havia CVE público nem pontuação CVSS publicada no fechamento do adesivo, muitas ferramentas e catálogos (por exemplo, o catálogo KEV de CISA) não poderão apontar o risco até que exista essa referência; você pode consultar o catálogo de versões do WordPress em a página de downloads e arquivos e o processo de divulgação de CISA em Known Exploited Vulnerabilities.

Se administrar um ou vários sites WordPress, veja a versão que realmente está executando e aplique a actualização a 6.9.5, 7.0.2 ou superior. Verificar a versão pode ser feita a partir do painel de administração, consultando o meta generator no HTML público (se não tiver sido removido), ou a partir de linha de comandos com WP- CLI: executarwp core versione atualizar comwp core updateSe tiver acesso. Não assuma que a atualização forçada já chegou a todos os seus servidores.

Enquanto não puder atualizar, existem mitigações provisórias que evitam que chamadas anônimas cheguem ao endpoint vulnerável, embora todas tenham custo funcional. Uma alternativa é bloquear no WAF tanto a rota JSON padrão /wp-json/batch/v1 como a variante por query string rest_route=/batch/v1; Assetnote sublinha que ambas devem ser bloqueadas porque o bloqueio só a primeira deixa um vetor aberto. Outra opção é desativar a API REST para acessos anônimos ou colocar um pequeno plugin que rejeite chamadas anônimas ao endpoint /batch/v1 usando o hook rest_pre_dispatch. Tenha em conta que essas medidas podem romper integrações legítimas que dependam da API.

A falta de um teste de exploração pública por agora não deve induzir a calma. O ecossistema WordPress tem um histórico de campanhas massivas que exploram falhas divulgadas e adesivos dias ou horas antes; se o código do adesivo estiver em um repositório público, os atacantes com conhecimento suficiente podem comparar versões e construir exploits rapidamente. É por isso que é crítico aplicar adesivos e monitorizar atividade anómala Antes de as digitalizaçãos e os exploits aparecerem na wild.

Acções específicas recomendadas: atualize quanto antes das versões corrigidas; se não puder atualizar imediatamente, bloquee as rotas indicadas na fronteira (WAF ou regras de servidor) e considere desativar a API REST para usuários anônimos até que esteja protegido. Revise logs web e de WAF procurando pedidos para /wp-json/batch/v1 ou contendo rest_route=/batch/v1, inspeccione arquivos modificados recentemente e verifique a presença de contas administrativas ou arquivos PHP suspeitos em wp-content. Faça cópias de segurança completas antes de qualquer intervenção, e, se suspeitar de compromisso, mantenha a instância desligada enquanto pesquisa.

Finalmente, lembre-se de que o alcance real do problema não é o número total de instalações do WordPress, mas as que executam versões afetadas publicadas desde dezembro de 2025 (6.9 em adiante). Se o seu site estiver em 6.8 ou acima não tiver este erro em particular, mas outras correcções estão pendentes nesses ramos; por exemplo, 6.8.6 aborda outra injeção SQL distinta. Manter uma política de atualização regular, segmentação de privilégios e monitorização de anomalias reduz drasticamente a janela de exposição contra estes erros de zero dia.