Uma requisição HTTP (Protocolo de Transferência de Hipertexto) anônima pode executar código em um site WordPress. A falha está no núcleo, então uma instalação limpa, com zero plugins, já é explorável.
Todos os sites nas versões 6.9 e 7.0 estavam dentro do alcance até a sexta-feira, quando o WordPress disponibilizou as versões 6.9.5 e 7.0.2 e ativou o que chama de atualizações forçadas por meio de seu sistema de autoatualização.
Adam Kues, da Assetnote, o braço de gestão de superfície de ataque da Searchlight Cyber, descobriu a falha e a reportou pelo programa do HackerOne do WordPress. A análise técnica, publicada sob o nome wp2shell, afirma que o ataque "não tem pré-condições e pode ser explorado por um usuário anônimo".
A empresa está guardando os detalhes técnicos por enquanto e disponibilizou em wp2shell.com uma ferramenta de verificação, para que os responsáveis possam testar suas próprias instâncias.
O WordPress lançou as versões 6.9.5 e 7.0.2 em 17 de julho de 2026, fechando uma falha de RCE (Execução Remota de Código) pré-autenticação no núcleo que pode ser acionada por uma requisição anônima em uma instalação padrão, sem plugins. Duas faixas de versões são afetadas:
- 6.9.0 a 6.9.4, corrigida na 6.9.5
- 7.0.0 a 7.0.1, corrigida na 7.0.2
O WordPress não informou se a atualização forçada alcança sites que desativaram as autoatualizações. Verifique o que está rodando de fato, em vez de presumir que o patch chegou.
O 7.1 beta 2 traz a mesma correção. Sites que ainda estão na 6.8 também têm uma atualização disponível, mas a 6.8.6 é para a segunda falha de injeção de SQL (Linguagem de Consulta Estruturada) do mesmo ciclo, reportada por outro time.
O texto da Searchlight estima que mais de 500 milhões de sites rodam WordPress. Esse número é o total da base instalada, não a população vulnerável: o código com falha só existe a partir da 6.9, e a 6.9 foi lançada em 2 de dezembro de 2025. Portanto, todos os sites afetados rodam uma versão com menos de oito meses de vida, e nenhum dos dois avisos informa quantos sites isso representa.
O WordPress é mais transparente sobre a classe da falha do que o pesquisador. Sua publicação de lançamento descreve a descoberta de Kues como "um problema de confusão de rota em lote da API REST (Interface de Programação de Aplicações) e injeção de SQL que leva à Execução Remota de Código". O lançamento cobre uma falha crítica e outra de alta severidade, e o WordPress não diz qual é qual.
A página da versão lista os três arquivos alterados pela 7.0.2, cobrindo as duas correções: /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php e /wp-includes/rest-api.php. O endpoint em lote não é novo. O WordPress o envia desde a 5.6, em novembro de 2020, e documenta publicamente o formato das requisições desde então. Nada publicado até agora explica o que mudou na 6.9 para abri-lo.
Nenhum dos avisos traz um identificador CVE (Vulnerabilidades e Exposições Comuns) ou uma pontuação CVSS (Sistema Comum de Pontuação de Vulnerabilidades), e nenhum registro de CVE havia aparecido até 18 de julho. Scanners e inventários baseados em CVE não vão sinalizar este caso, e a CISA (Agência de Segurança Cibernética e de Infraestrutura dos EUA) precisa de um CVE antes de poder incluir algo no catálogo KEV (Vulnerabilidades Exploradas Conhecidas). Acompanhe pelo número de versão.
Se não for possível atualizar hoje
Todas as mitigações oferecidas pela Searchlight se resumem a manter os chamadores anônimos longe do endpoint em lote. Três opções, todas paliativas até a atualização e todas com potencial de quebrar integrações legítimas:
- Em um WAF (Firewall de Aplicação Web), bloqueie tanto /wp-json/batch/v1 quanto rest_route=/batch/v1. A empresa deixa claro que os dois precisam cair, porque uma regra cobrindo apenas o caminho /wp-json deixa a rota via string de consulta aberta.
- Desativar a WP REST API, o que elimina em massa o acesso REST não autenticado.
- Um plugin drop-in curto, publicado pela empresa, que rejeita requisições anônimas a /batch/v1 em rest_pre_dispatch.
Nenhuma tentativa de exploração havia sido relatada até 18 de julho. Sem um CVE para etiquetar e sem assinatura pública para comparar, ninguém está realmente procurando ainda.
A exploração em massa do WordPress já é um mercado. Antes de seu servidor vazar em junho, uma única falha em plugin de cache levou o grupo WP-SHELLSTORM a invadir mais de 17 mil sites, segundo a própria contabilidade do grupo. Aquela falha já era pública, já tinha correção e só funcionava com uma configuração fora do padrão.
Quando o Drupal corrigiu uma injeção de SQL anônima em seu próprio núcleo em maio, a Searchlight transformou aquela correção pública em uma análise no mesmo dia, com duas provas de conceito funcionais. A falha era de outra pessoa e o patch também; nada obriga a empresa a fazer o mesmo com a própria. Mas foi o tempo que bastou, e quem definiu esse relógio agora aposta que o silêncio compra tempo para os defensores.
O núcleo do WordPress é de código aberto, e as versões 7.0.1 e 7.0.2 estão no arquivo público de lançamentos, então a comparação está disponível para quem quiser. Esse é o dilema de todo projeto de código aberto: é impossível enviar a correção sem enviar o mapa da falha, e a única alavanca que resta é a velocidade com que o patch chega aos sites antes que alguém o leia.
O WordPress puxou essa alavanca na sexta-feira. O tráfego contra batch/v1 mostrará quando os atacantes chegarem, e as estatísticas de versão do próprio WordPress mostrarão se o patch chegou primeiro. Apenas um desses números costuma virar notícia.
