A falha CVE-2026-60137 no WordPress é uma vulnerabilidade de injeção de SQL que afeta o núcleo do sistema nas versões 6.8.x até 7.0.1 e tem correção obrigatória marcada pelo governo dos Estados Unidos para 4 de agosto de 2026. O CISA adicionou a vulnerabilidade ao seu catálogo de exploração conhecida KEV em 21 de julho de 2026 e exige que órgãos federais americanos apliquem a correção até 4 de agosto de 2026. Em ambientes com plugins ou temas que repassam dados não confiáveis ao parâmetro vulnerável, o ataque pode extrair registros do banco de dados e, em versões 6.9 ou superiores, escalar para execução remota de código. A atualização para WordPress 6.8.6, 6.9.5 ou 7.0.2 elimina o problema, e o time do WordPress habilitou atualizações automáticas forçadas devido à gravidade do caso.

Detalhes da falha SQL injection

O WordPress não sanitiza adequadamente o parâmetro author__not_in da classe WP_Query, permitindo injeção de SQL quando um plugin ou tema repassa entrada não confiável a esse parâmetro. O objeto WP_Query é usado em todo o ecossistema WordPress para montar consultas a posts, e o argumento author__not_in serve para excluir autores dos resultados. Quando a entrada chega sem escape adequado, um atacante consegue injetar comandos SQL maliciosos na consulta.

O impacto depende do que cada extensão faz com o parâmetro. A anotação oficial do projeto classifica o caso isolado como gravidade moderada, com CVSS 5.9, mas a análise da CISA atribui 9.1 crítico ao considerar a automatização do ataque e o impacto técnico total. A diferença entre as duas leituras reflete justamente o risco real de encadeamento com outra falha do núcleo.

Versões afetadas Tipo de impacto Versão corrigida
6.8.0 a 6.8.5 Injeção de SQL 6.8.6
6.9.0 a 6.9.4 SQL com cadeia de RCE 6.9.5
7.0.0 a 7.0.1 SQL com cadeia de RCE 7.0.2

Encadeamento leva a execução remota

O cenário mais grave não é a injeção isolada, mas a combinação com outra falha do núcleo. A vulnerabilidade de SQL injection combinada com uma falha de confusão de rota em lote da REST API identificada como CVE-2026-63030, eleva o impacto a execução remota de código nas versões 6.9 e superiores. Em termos práticos, um atacante remoto consegue executar código arbitrário no servidor sem credenciais e assumir controle total do site.

A segunda falha explora uma confusão de rota no endpoint de lotes (batch) da REST API. Em instalações com WordPress 6.8 apenas a injeção de SQL está presente; nas versões 6.9 e 7.0 a presença da segunda brecha abre o caminho até RCE. Por isso, manter uma rotina de verificação de vulnerabilidades com scanners e conferir a versão instalada em todos os sites faz parte da defesa básica.

Prazo do CISA KEV e prioridade

A entrada no Known Exploited Vulnerabilities Catalog não é apenas um aviso: indica exploração ativa confirmada. O modelo SSVC mantido pela CISA classifica a exploração como ativa, a automatização como possível e o impacto técnico como total, o que justifica a janela curta de remediação. Órgãos civis federais americanos sujeitos à diretriz BOD 26-04 precisam corrigir dentro do prazo, e qualquer organização privada deve tratar o caso com a mesma urgência.

A combinação de exploração ativa com RCE sem autenticação transforma a atualização na prioridade número um de toda equipe que mantém instalações WordPress expostas à internet. Adiar a correção depois do prazo de 4 de agosto mantém o servidor em estado vulnerável diante de ataques automatizados.

Como atualizar o WordPress

As versões corrigidas são WordPress 6.8.6, 6.9.5 e 7.0.2, lançadas em 17 de julho de 2026, e a correção também foi backportada para a beta do 7.1. O WordPress.org habilitou atualizações automáticas forçadas para as versões afetadas, mas administradores devem confirmar manualmente o estado de cada instalação.

  1. Faça backup completo do banco de dados e dos arquivos antes de qualquer alteração.
  2. Acesse o painel administrativo, abra a seção Painel → Atualizações e clique em Atualizar agora.
  3. Confirme se a versão instalada passou a ser 6.8.6, 6.9.5 ou 7.0.2, conforme o ramo em uso.
  4. Audite plugins e temas que usam WP_Query com parâmetros de entrada do usuário e corrija o saneamento.
  5. Monitore os logs de acesso em busca de payloads de injeção nas semanas seguintes à atualização.

Equipes com várias instalações podem automatizar o processo via WP-CLI com o comando wp core update ou adotar ferramentas de gestão de cibersegurança para conferir a versão em lote.

Fontes