A exploração ativa de duas falhas encadeadas no WordPress Core, batizadas de wp2shell, permite que invasores assumam o controle total de sites sem qualquer login. A CISA incluiu os dois CVEs no catálogo de vulnerabilidades em exploração ativa (KEV) em 21 de julho de 2026 e fixou prazos de remediação de poucos dias. Sites nas versões afetadas devem ser atualizados imediatamente para 6.8.6, 6.9.5 ou 7.0.2, as versões corrigidas lançadas em 17 de julho.
Diferente das falhas típicas em plugins e temas, o wp2shell atinge o próprio núcleo do WordPress, o software que sustenta cerca de 40% da web pública. Por residir no Core, até instalações “limpas”, sem extensões, ficam expostas quando acessíveis pela internet, o que amplia drasticamente o universo de alvos potenciais.
Como o wp2shell funciona
O ataque combina duas vulnerabilidades complementares. A primeira, CVE-2026-60137, é uma injeção de SQL no parâmetro author__not_in do WP_Query, que não sanitiza corretamente a entrada quando um plugin ou tema repassa dados não confiáveis. A segunda, CVE-2026-63030, é uma confusão de rota no endpoint batch da REST API, acessível em /wp-json/batch/v1. Sozinhas, cada falha tem alcance limitado; combinadas, um atacante sem autenticação alcança a injeção de SQL pelo endpoint batch e escala para execução remota de código (RCE) no servidor. A cadeia não exige credenciais fracas, plugins vulneráveis nem engenharia social: basta uma instalação exposta em versão vulnerável.
Segundo o registro do NVD, a CVE-2026-63030 recebeu CVSS 9.8 (crítico) na avaliação do WPScan, enquanto a CVE-2026-60137 foi classificada em 9.1 (crítico) pela análise da CISA. A agência marcou ambas como de exploração ativa, automatizável e de impacto técnico total, o que significa comprometimento completo de confidencialidade, integridade e disponibilidade.
Versões afetadas e correção
A versão 7.0.2, lançada em 17 de julho de 2026, corrige uma falha crítica e uma de alta gravidade. A equipe do WordPress ativou a atualização forçada via sistema de autoatualização para as versões afetadas, mas administradores devem verificar o resultado manualmente, pois configurações de hospedagem podem desativar o mecanismo. A tabela abaixo resume o impacto por ramo de versão.
| Versão do WordPress | Impacto | Atualizar para |
|---|---|---|
| 7.0.0–7.0.1 | Cadeia completa de RCE sem login | 7.0.2 |
| 6.9.0–6.9.4 | Cadeia completa de RCE sem login | 6.9.5 |
| 6.8.0–6.8.5 | Apenas injeção de SQL | 6.8.6 |
| Anteriores a 6.8 | Não afetadas | — |
Atenção: a ramificação 6.8.x só contém a CVE-2026-60137. A cadeia wp2shell depende da CVE-2026-63030, presente a partir da 6.9, por isso instalações 6.8.x estão sujeitas à injeção de SQL, mas não ao RCE remoto sem autenticação.
Prazos e ações obrigatórias
Sob a diretiva BOD 26-04, a CISA exige que agências civis federais americanas remedeiem a CVE-2026-63030 até 24 de julho de 2026 e a CVE-2026-60137 até 4 de agosto de 2026. A inclusão no KEV confirma uso em ataques reais e obriga triagem forense para avaliar comprometimento antes ou durante a aplicação do patch. Organizações privadas podem usar esses prazos como referência para resposta de emergência, já que a janela entre exploração massiva e defesa costuma ser curta.
Mitigação temporária e detecção
Quando a correção imediata não for viável, bloqueie os caminhos /wp-json/batch/v1 e /?rest_route=/batch/v1 no WAF ou no balanceador de carga; bloquear apenas um deles deixa a rota alternativa aberta. Essa medida é um paliativo e pode quebrar integrações legítimas que usam o endpoint, então deve ser tratada como ponte até a atualização. Em seguida, execute o procedimento de verificação de integridade:
- Confirme a versão de cada instalação com
wp core versionou no painel “Na primeira vista” do administrador. - Rode
wp core verify-checksumsem instâncias não corrigidas e investigue qualquer divergência nos arquivos do Core. - Revise logs em busca de requisições POST para o endpoint batch com strings de SQL (SELECT, IF, SLEEP) nos parâmetros author__not_in ou author__exclude.
- Procure contas de administrador recém-criadas e desconhecidas, além de arquivos PHP estranhos em wp-content/uploads ou wp-content/plugins.
- Investigue redirecionamentos injetados ou JavaScript não autorizado inserido em posts e temas.
O monitoramento contínuo de logs é essencial para detectar tentativas de exploração em estágio inicial, quando ainda há chance de conter o incidente. Um scanner de vulnerabilidades como o OpenVAS ajuda a mapear a exposição antes que o atacante chegue, e uma política disciplinada de gestão de acessos e menor privilégio reduz o raio de dano caso a exploração tenha êxito. Sites críticos merecem ainda verificação de integridade de arquivos e segmentação de rede para isolar o ambiente administrativo.