Em 17 de julho de 2026, a equipe central do WordPress lançou a versão 7.0.2, um pacote de segurança que corrige duas vulnerabilidades sérias no núcleo do sistema. A mais grave delas é uma injeção de SQL não autenticada, acessível por meio do endpoint de lote (batch) da REST API, explorada a partir de uma confusão entre rota e manipulador de requisições que burla a validação de entrada. Tanto a equipe do WordPress quanto o pesquisador que reportou o problema classificam a cadeia completa como capaz de gerar execução remota de código.
A empresa de segurança Patchstack afirmou ter implementado regras de mitigação imediata (RapidMitigate) assim que tomou conhecimento das falhas, e já registrou tentativas de exploração ativa em seus logs de monitoramento. A companhia recomenda que todos os administradores de sites atualizem imediatamente e verifiquem se há usuários desconhecidos cadastrados em seus painéis, já que há indícios de que a vulnerabilidade está sendo explorada na prática, podendo levar à tomada total de controle do site.
Atualização forçada e versões corrigidas
Por se tratar de uma falha não autenticada e passível de exploração em massa, a equipe do WordPress tratou o caso como prioridade máxima e chegou a aplicar uma atualização forçada nos sites afetados. Ainda assim, recomenda-se que administradores confirmem manualmente se estão na versão mais recente de seu respectivo ramo de atualização:
- WordPress 7.0.2 — corrige as duas vulnerabilidades;
- WordPress 6.9.5 — traz o backport das duas correções;
- WordPress 6.8.6 — não é afetado pela falha de confusão de rota, mas recebeu o backport da correção de injeção SQL.
Como funciona a cadeia de ataque
As duas falhas devem ser entendidas como partes de um único ataque em duas etapas: uma brecha na camada REST que anula a validação de entrada, alimentando uma falha na camada de consultas que transforma dados não validados em comandos SQL maliciosos.
A primeira vulnerabilidade (CVE-2026-60137), classificada como de alta severidade e presente desde a versão 6.8, está na forma como a função WP_Query constrói a cláusula SQL para a variável de consulta author__not_in. Até a versão 7.0.1, esse valor só era higienizado quando chegava no formato de array. O problema é que, se o parâmetro chegasse como uma string, toda a etapa de sanitização era simplesmente ignorada, e o valor bruto acabava sendo inserido diretamente na cláusula WHERE da consulta SQL, sem qualquer conversão para número inteiro ou parametrização segura.
Essa falha é chamada de “facilitada” porque, em condições normais, o parâmetro author__not_in não pode ser manipulado diretamente por um atacante — o parâmetro equivalente na REST API, author_exclude, é validado como uma lista de números inteiros antes de chegar até ali. A brecha só se torna explorável quando outro mecanismo consegue burlar esse processamento e permitir que um valor não validado passe adiante — papel exercido pela segunda vulnerabilidade.
A correção aplicada direciona o valor pela função wp_parse_id_list(), que converte qualquer entrada em uma lista limpa de números inteiros antes que ela alcance a consulta, eliminando a dependência do tipo de dado recebido.
A falha crítica no endpoint de lote da REST API
A segunda vulnerabilidade (CVE-2026-63030), classificada como crítica e presente desde a versão 6.9, está no endpoint de lote da REST API, gerenciado pela função WP_REST_Server::server_batch_request_v1(), que permite agrupar diversas sub-requisições em uma única chamada. O processo normal analisa cada sub-requisição, associa-a a um manipulador de rota, valida-a e só então a executa.
A causa raiz é uma dessincronização de índices entre os arranjos internos criados pelo sistema durante esse processo. As correspondências (matches) são adicionadas a um array compactado apenas quando a sub-requisição não resulta em erro — porém, na hora de despachar as requisições, o sistema lê essas correspondências pelo índice original da requisição, não pelo índice compactado.
Um atacante pode explorar essa brecha inserindo, como primeira sub-requisição de um lote, um caminho inválido como http://, que falha na função wp_parse_url() e gera um erro. Essa entrada permanece na lista de requisições, mas nunca é adicionada à lista de correspondências, provocando um deslocamento de uma posição em todas as buscas de manipuladores seguintes. Aninhando um segundo lote, o atacante repete esse deslocamento em um nível mais profundo, conseguindo posicionar uma requisição do tipo GET /wp/v2/posts?author_exclude=[código malicioso] de forma que ela seja:
- validada segundo as regras do manipulador de criação de posts (POST), no qual author_exclude não é um filtro de coleção reconhecido — o que faz com que a validação que normalmente rejeitaria um valor não numérico simplesmente não seja executada;
- e executada segundo o manipulador da rota de coleção (GET), que aciona a função get_items() sem exigir autenticação.
O núcleo do problema de segurança está no fato de que, após esse deslocamento, método, rota, esquema de validação, permissão de acesso e função final de execução deixam de pertencer ao mesmo manipulador — a validação é feita por um handler, mas a execução ocorre em outro completamente diferente. É esse desalinhamento que permite que o parâmetro author_exclude, sem qualquer validação, chegue até o WP_Query e acione a falha de injeção SQL descrita anteriormente.
A correção aplicada envolve duas mudanças. A primeira mantém os arranjos de índices sempre alinhados, incluindo também os erros na lista de correspondências. A segunda introduz uma trava de reentrância, impedindo que um novo ciclo da REST API seja iniciado enquanto outro despacho ainda está em andamento — as sub-requisições internas passam a obrigatoriamente utilizar a função dispatch(), em vez de iniciar um novo processo de atendimento de requisições.
Recomendação final
A versão 7.0.2 do WordPress corrige, portanto, uma cadeia de ataque em duas etapas: uma injeção SQL por confusão de tipos na função WP_Query, presente desde a versão 6.8, e — a partir da versão 6.9 — uma falha de confusão entre rota e manipulador no endpoint de lote da REST API, que desvincula a validação da execução e permite que dados não validados alimentem a primeira falha, tudo isso sem necessidade de autenticação.
Diante da gravidade do problema e das evidências de exploração ativa registradas pela Patchstack, recomenda-se fortemente que administradores de sites WordPress atualizem seus sistemas imediatamente ou adotem soluções de mitigação em tempo real enquanto a atualização não é aplicada.
