A cadeia de vulnerabilidades conhecida como wp2shell combina duas falhas no núcleo do WordPress — CVE-2026-63030 e CVE-2026-60137 — para permitir execução remota de código sem autenticação em instalações padrão das versões 6.9 e 7.0. Nenhuma credencial, plugin ou interação do usuário é necessária para a exploração. A CISA confirmou exploração ativa em 21 de julho de 2026 e impôs prazo de remediação de três dias para agências federais dos Estados Unidos. A remediação consiste em atualizar para WordPress 6.9.5, 7.0.2 ou 6.8.6, versões lançadas no mesmo dia da divulgação.
Como o ataque wp2shell funciona
A exploração abusa do endpoint /wp-json/batch/v1 da REST API. O processador executa validação e despacho em loops separados: quando wp_parse_url() falha ao analisar o caminho de uma subrequisição, o erro entra no array de validação mas não no de correspondências. Essa dessincronização despacha cada requisição subsequente para o manipulador errado — uma condição de confusão de rota classificada como CWE-436.
Essa confusão contorna restrições de acesso que normalmente exigiriam autenticação e leva à injeção SQL no parâmetro author__not_in do WP_Query, rastreada como CVE-2026-60137. A injeção ocorre porque o valor do parâmetro é interpolado diretamente em SQL bruto quando fornecido como string escalar, e a validação que normalmente o impediria é anulada pela dessincronização do batch.
Com ambas as falhas presentes, uma chamada recursiva ao batch contorna restrições de GET, produz injeção SQL baseada em UNION sem credenciais e escala para execução de código. A cadeia cria uma conta de administrador usando internos do WordPress; o atacante faz login e carrega um plugin malicioso, obtendo controle total do servidor. Nenhuma das duas falhas isoladamente permite execução de código não autenticada — apenas o encadeamento completa o caminho de ataque. A vulnerabilidade foi descoberta por Adam Kues, da Assetnote e Searchlight Cyber, e divulgada em 17 de julho de 2026.
Versões afetadas e correções
A tabela abaixo resume quais versões do WordPress são afetadas e a correção correspondente:
| Versão do WordPress | CVEs aplicáveis | Atualizar para |
|---|---|---|
| 7.0.0 a 7.0.1 | CVE-2026-63030 + CVE-2026-60137 | 7.0.2 |
| 6.9.0 a 6.9.4 | CVE-2026-63030 + CVE-2026-60137 | 6.9.5 |
| 6.8.0 a 6.8.5 | Apenas CVE-2026-60137 | 6.8.6 |
O WordPress lançou as versões corrigidas 6.8.6, 6.9.5 e 7.0.2 em 17 de julho de 2026, simultaneamente à divulgação pública. O projeto forçou atualizações automáticas para instalações afetadas com o recurso habilitado. Administradores devem confirmar manualmente no painel que cada site concluiu a atualização, pois configurações de hospedagem podem desabilitar atualizações automáticas.
Exploração confirmada em ataques reais
Em 21 de julho de 2026, quatro dias após a divulgação, a CISA adicionou ambas as falhas ao catálogo de Vulnerabilidades Conhecidas como Exploradas. O prazo para agências federais corrigirem CVE-2026-63030 foi 24 de julho — três dias após a inclusão. Para CVE-2026-60137, o prazo é 4 de agosto. Ambas seguem a Diretiva BOD 26-04.
A pesquisa da Wiz identificou múltiplos atores explorando a cadeia contra instâncias auto-hospedadas na nuvem. As atividades de pós-exploração observadas incluem upload de plugins maliciosos via wp-admin/plugin-install.php, enumeração de usuários administradores através do endpoint /wp-json/wp/v2/users e tentativas de inclusão de arquivo local visando credenciais do banco de dados em wp-config. Os dados indicavam que 60% das organizações com WordPress tinham ao menos uma instância vulnerável na data de publicação, e 25% expunham um servidor vulnerável à internet.
Pesquisadores documentaram webshells implantados após exploração bem-sucedida, incluindo um backdoor de uma linha que retorna HTTP 404 como técnica de evasão e um webshell de 150 KB disfarçado como plugin CMSmap, com interface gráfica, gerenciamento de arquivos e módulos de escalonamento de privilégio.
Sinais de comprometimento e detecção
A detecção de exploração depende de revisar logs de acesso HTTP em busca de padrões específicos. Respostas HTTP 207 (Multi-Status) ou HTTP 200 para requisições ao endpoint /wp-json/batch/v1 são indicadores de alta fidelidade de exploração bem-sucedida. Strings de user-agent contendo wp2shell ou rezwp2shell identificam ferramentas de exploração automatizadas.
Após corrigir, equipes de segurança devem investigar sinais de comprometimento mesmo em sites já atualizados. Os indicadores prioritários são contas de administrador desconhecidas criadas recentemente, plugins ou arquivos PHP não reconhecidos, alterações em posts ou arquivos de tema e tráfego de saída suspeito. A análise deve cobrir o período desde 17 de julho de 2026. Identificar padrões suspeitos exige disciplina analítica, conforme detalhado em nosso guia sobre monitoramento de logs na defesa digital.
Plano de resposta imediato
A remediação segue uma ordem clara de prioridades. Primeiro, atualize todas as instalações WordPress expostas à internet para 6.9.5 ou 7.0.2 imediatamente e verifique no painel que a versão instalada corresponde à corrigida. Se a atualização imediata não for viável, bloqueie o acesso anônimo ao endpoint /wp-json/batch/v1 (ou ?rest_route=/batch/v1) no WAF ou balanceador de carga como mitigação temporária. Revise logs de acesso HTTP desde 17 de julho em busca dos indicadores listados acima. Remova contas de administrador não autorizadas e plugins ou arquivos PHP desconhecidos. Rotacione credenciais de banco de dados e chaves de autenticação se houver evidência de comprometimento, e restaure de backup verificado se houver persistência confirmada.
O GitHub Security Advisory classifica a vulnerabilidade como Critical e recomenda atualização imediata devido à gravidade. Um controle estruturado de aplicação de patches, como abordado em nossa análise sobre cuidados operacionais de cibersegurança, diferencia equipes que contêm incidentes das que os descobrem tardiamente.