A cadeia wp2shell combina duas vulnerabilidades no WordPress Core para permitir execução remota de código (RCE) sem autenticação, sem necessidade de plugin, tema ou credenciais válidas. A falha foi corrigida em 17 de julho de 2026 nas versões 7.0.2, 6.9.5 e 6.8.6, mas milhões de instalações permanecem desatualizadas e sob risco de invasão ativa. A CISA adicionou ambas as falhas ao catálogo Known Exploited Vulnerabilities (KEV) em 21 de julho de 2026, confirmando exploração em ambiente real.
Como funciona a wp2shell
A cadeia wp2shell explora uma falha de confusão de rota no endpoint batch da REST API do WordPress (CVE-2026-63030, CVSS 9.8) encadeada com uma injeção SQL no parâmetro author__not_in do WP_Query (CVE-2026-60137). Sozinha, a injeção SQL não é alcançável sem autenticação em uma instalação padrão, pois a validação da REST API normalmente higieniza a entrada afetada. A confusão de rota contorna essa validação: o atacante envia requisições batch recursivas que entregam SQL não higienizado ao banco de dados. A partir daí, o exploit demonstrado abusa da lógica de cache de posts e de personalização do WordPress para assumir temporariamente privilégios de administrador, criar uma nova conta administrativa e fazer upload de um plugin malicioso que executa código no servidor. A vulnerabilidade CVE-2026-60137, isolada, afeta as versões 6.8.0 até 6.8.5, 6.9.0 até 6.9.4 e 7.0.0 até 7.0.1; o CVE-2026-63030, que completa a cadeia de execução remota de código, afeta apenas as ramificações 6.9.x e 7.0.x.
Versões afetadas e impacto
O WordPress 7.0.1, a versão imediatamente anterior ao patch 7.0.2, corresponde sozinha a cerca de 5,11 milhões de instalações afetadas. A empresa de inteligência Censys estima aproximadamente 62,8 milhões de instâncias de WordPress em todo o mundo em 20 de julho de 2026, das quais cerca de 12% (7,74 milhões) estariam dentro do intervalo elegível à cadeia wp2shell, com concentração em provedores de hospedagem como AWS, DigitalOcean, Hetzner, OVH e GoDaddy. Falhas semelhantes no ecossistema de extensões já provocaram ondas de exploração — como o CVE-2026-8206 no Kirki, que permitiu sequestro de contas administrativas em WordPress —, mas a wp2shell é particularmente grave por residir no núcleo do CMS e exigir zero credenciais para atingir uma instalação padrão.
| CVE | Tipo | CVSS (WPScan) | Ramificações afetadas |
|---|---|---|---|
| CVE-2026-63030 | Confusão de rota na REST API (CWE-436) | 9,8 Crítico | 6.9.0–6.9.4, 7.0.0–7.0.1 |
| CVE-2026-60137 | Injeção SQL em WP_Query (CWE-89) | 5,9 Médio | 6.8.0–6.8.5, 6.9.0–6.9.4, 7.0.0–7.0.1 |
| Correção | Atualização de segurança | — | 6.8.6, 6.9.5, 7.0.2 |
Como corrigir imediatamente
O WordPress liberou atualização forçada via sistema de autoatualização para as versões afetadas, mas administradores devem confirmar manualmente a versão em execução. O procedimento prioritário de remediação é:
- Atualize imediatamente para WordPress 7.0.2, 6.9.5 ou 6.8.6, conforme a ramificação usada pelo site.
- Confirme a versão no painel do WordPress ou via arquivo
readme.htmlna raiz do site. - Verifique se a autoatualização de versões menores está habilitada em Configurações.
- Se não for possível atualizar de imediato, bloqueie anonimamente o endpoint
/wp-json/batch/v1e?rest_route=/batch/v1via WAF como medida emergencial. - Revise plugins e temas suspeitos instalados recentemente, mesmo os não autorizados.
A atualização elimina as duas vulnerabilidades encadeadas. O WordPress orienta baixar o pacote oficial em wordpress.org e aplicar pelo painel em Ferramentas → Atualizações, ou executar o WP-CLI com wp core update em ambientes gerenciados por linha de comando.
Verifique sinais de invasão
Após aplicar o patch, investigue possíveis comprometimentos anteriores à correção. A CISA exige, por meio da diretiva BOD 26-04, que órgãos federais verifiquem se houve comprometimento antes da aplicação da correção — prática recomendada para qualquer organização. Checklist mínimo de triagem forense:
- Pesquise contas de administrador desconhecidas criadas após 17 de julho de 2026.
- Inspecione uploads de plugins novos no diretório
wp-content/plugins. - Revise logs de acesso à REST API em busca de requisições batch recursivas e anômalas.
- Procure webshells e arquivos PHP modificados na árvore de arquivos do site.
- Considere redefinir credenciais de banco de dados e chaves de autenticação (SALT).
Assim como na falha do Avada Builder que expôs 1 milhão de sites WordPress, a presença de arquivos inesperados e contas administrativas recém-criadas é um indicador forte de exploração bem-sucedida.