O prazo de remediação que a CISA fixou para a CVE-2026-60137 no núcleo do WordPress expira em 4 de agosto de 2026. Qualquer instalação que ainda execute as versões 6.8.0 a 6.8.5, 6.9.0 a 6.9.4 ou 7.0.0 a 7.0.1 permanece vulnerável a uma injeção de SQL que, combinada com outra falha, abre caminho para execução remota de código sem autenticação. A ação exigida é direta: atualizar para 6.8.6, 6.9.5 ou 7.0.2, releases de segurança publicados pela equipe do WordPress em 17 de julho de 2026.
A catalogação da falha como Known Exploited Vulnerability (KEV) transforma o que seria uma atualização rotineira em uma obrigação com prazo. Agências federais dos Estados Unidos devem cumprir a remediação no cronograma definido, e o catálogo serve de referência de prioridade para organizações privadas em todo o mundo. O detalhe crítico é que a exploração já é ativa e há provas de conceito públicas, o que reduz drasticamente a janela para correção.
O que o prazo KEV significa
A entrada de uma vulnerabilidade no catálogo KEV não cria a falha, mas estabelece um prazo de correção baseado em evidência de exploração no mundo real. No caso da CVE-2026-60137, a CISA registrou a data de adição em 21 de julho de 2026 e fixou 4 de agosto de 2026 como data limite para aplicação das correções. Quem administra WordPress deve entender o catálogo como um sinal de prioridade máxima: a janela de 14 dias reflete não o tempo ideal, mas o tempo considerado aceitável diante de exploração ativa.
A diretiva de aplicação associada, a BOD 26-04, exige não apenas o patch, mas também avaliação da exposição do ativo à internet e triagem forense quando há indício de comprometimento. Em outras palavras, atualizar resolve a causa, mas não apaga evidência de intrusão anterior. Para entender o histórico da cadeia de exploração, vale conferir a análise da cadeia wp2shell publicada no portal e o detalhamento técnico do RCE sem login que afeta o WordPress em massa.
Versões seguras e cadeia wp2shell
A falha reside no parâmetro author__not_in da classe WP_Query, que permite injeção de SQL quando um plugin ou tema repassa entrada não confiável a esse parâmetro. A vulnerabilidade foi classificada como CWE-89 e afeta exclusivamente o WordPress 6.8 e superiores. As versões corrigidas — 6.8.6 para a linha 6.8.0 a 6.8.5, 6.9.5 para 6.9.0 a 6.9.4 e 7.0.2 para 7.0.0 a 7.0.1 — foram publicadas em 17 de julho de 2026.
| Linha afetada | Versão corrigida | Detalhe |
|---|---|---|
| 6.8.0 a 6.8.5 | 6.8.6 | Só afetada pela injeção de SQL |
| 6.9.0 a 6.9.4 | 6.9.5 | Afetada pela SQLi e pela falha de RCE |
| 7.0.0 a 7.0.1 | 7.0.2 | Afetada pela SQLi e pela falha de RCE |
O risco cresce porque a CVE-2026-60137 não age sozinha nas versões 6.9 e 7.0. Encadeada com a CVE-2026-63030 — uma falha de confusão de rota no endpoint batch da REST API — ela permite que um atacante remoto e não autenticado obtenha execução remota de código em instalações padrão do WordPress, sem necessidade de plugin, tema ou credenciais válidas. Essa combinação, batizada de wp2shell, é o que justifica a classificação de impacto técnico total e a pressa na remediação.
O WordPress habilitou atualizações forçadas via sistema de auto-update para as versões afetadas, mas isso não garante cobertura total. Sites com auto-update desativado, hospedagens que bloqueiam o processo ou instalações muito customizadas podem permanecer defasadas, exigindo verificação manual.
Como verificar a correção
Com o prazo vencendo, a verificação deve ser imediata e objetiva. Antes de qualquer ação, faça um backup completo do banco de dados e dos arquivos para permitir rollback e triagem forense caso já exista comprometimento. Depois, siga o procedimento abaixo para cada instalação sob sua responsabilidade.
- Confirme a versão instalada: no painel administrativo, acesse a área “Atualizações” ou verifique o rodapé do painel; o número exato deve ser 6.8.6, 6.9.5 ou 7.0.2.
- Aplique a atualização: clique em “Atualizar agora” ou baixe o pacote oficial em wordpress.org; não use pacotes de origem desconhecida.
- Valide o auto-update: se a atualização automática falhou, investigue restrições da hospedagem, permissões de arquivo ou bloqueio do cron do WordPress.
- Faça a triagem forense: procure indicadores de comprometimento, como contas administrativas desconhecidas, plugins ou temas inseridos sem autorização e web shells no diretório de arquivos.
- Rotacione credenciais: troque senhas de administrador, chaves de API e credenciais de banco de dados se houver qualquer sinal de acesso indevido.
- Documente a remediação: registre versão final, data da aplicação e resultado da triagem para fins de conformidade com a BOD 26-04.
Para instalações gerenciadas em larga escala, automatize a verificação de versão via WP-CLI (wp core version) ou consulta direta ao endpoint de versão, cruzando o resultado com o inventário de ativos. Sites que não puderem ser atualizados imediatamente devem ser isolados da internet até a correção.
Fontes
- CISA — CVE-2026-60137 no Known Exploited Vulnerabilities Catalog: cisa.gov
- WordPress.org — WordPress 7.0.2 Release: wordpress.org
- GitHub Advisory (Vendor) — GHSA-fpp7-x2x2-2mjf: github.com
- NVD — CVE-2026-60137: nvd.nist.gov