Detector de PoC & validador seguro para a cadeia de vulnerabilidades WP2Shell do WordPress: CVE-2026-63030 (confusão de rota de lote REST) + CVE-2026-60137 (injeção SQL author__not_in). Apenas para testes de segurança autorizados.
Cobertura de CVE: CVE-2026-63030 e CVE-2026-60137 Uso pretendido: Somente testes de segurança autorizados, validação defensiva e laboratórios descartáveis localhost
WP2Shell é uma cadeia de vulnerabilidades do WordPress Core que combina um bug de confusão de rota em lote da REST API pré-autenticação (CVE-2026-63030) com uma primitiva de injeção SQL author__not_in do WP_Query (CVE-2026-60137). Este repositório fornece um scanner de prova de conceito em Python e um validador seguro para que defensores possam identificar instalações afetadas do WordPress, confirmar o comportamento vulnerável em um laboratório isolado e verificar a correção — sem precisar extrair dados ou obter execução de código.
Este projeto identifica instalações do WordPress e valida as duas primitivas de vulnerabilidade associadas à cadeia de vulnerabilidades WP2Shell do WordPress Core:
WP_Query::author__not_in, que pode resultar em injeção SQL quando uma entrada controlada pelo atacante atinge o parâmetro.Quando ambas as condições estão presentes, uma requisição não autenticada pode alcançar a construção SQL vulnerável através do endpoint de lote da REST API do WordPress. Avisos públicos descrevem o impacto combinado como potencialmente levando à execução remota de código.
Este repositório deve ser usado apenas em sistemas que você possui ou está explicitamente autorizado a testar. Prefira um laboratório isolado em Docker ou máquina virtual vinculado a 127.0.0.1.
O arquivo fonte atual contém funcionalidades de alteração de estado, incluindo tentativas de extração de dados do banco de dados, tentativas de escrita de arquivo, fluxos de autenticação, criação de administrador, upload de plugin e execução de comandos.
Versões afetadas do WordPress podem perder o alinhamento entre matrizes internas usadas para rastrear:
Quando um membro de lote malformado é aceito em uma matriz interna mas não em outra, requisições posteriores podem se associar ao manipulador errado. Uma requisição pode, portanto, ser validada como uma rota, mas executada usando o callback de outra rota.
Impacto de segurança:
author__not_inA implementação afetada do WP_Query não normaliza consistentemente author__not_in antes de usá-lo para construir uma condição SQL NOT IN (...).
O parâmetro normalmente espera uma lista de IDs de autor inteiros. Se uma string escalar atingir a construção da consulta vulnerável sem a validação de esquema REST pretendida, uma estrutura SQL insegura pode sobreviver na consulta ao banco de dados.
Impacto de segurança:
| Ramo do WordPress | Afetado | Versão corrigida |
|---|---|---|
| 6.8.x | Apenas CVE-2026-60137: 6.8.0–6.8.5 | 6.8.6 |
| 6.9.x | Ambos os problemas: 6.9.0–6.9.4 | 6.9.5 |
| 7.0.x | Ambos os problemas: 7.0.0–7.0.1 | 7.0.2 |
| 7.1 pré-lançamento | Beta 1 afetado | Beta 2 |
| Anteriores ao 6.8 | Não afetado por esses dois CVEs | N/A |
O WordPress lançou correções em 17 de julho de 2026 e habilitou atualizações automáticas forçadas para instalações afetadas devido à gravidade.
Unauthenticated client | v WordPress REST batch endpoint | v Malformed batch member creates request/handler misalignment | v Later request is validated against one route but dispatched using another route's handler | v Scalar author_exclude reaches WP_Query as author__not_in | v Unsafe value reaches SQL NOT IN (...) construction | v Blind SQL timing or Boolean oracle | v Potential database compromise | v Potential application-level compromise and RCE
O detector deve parar após confirmar as primitivas de rota-confusão e injeção SQL. Não é necessário extrair dados ou executar comandos para estabelecer que uma instalação afetada é vulnerável.
---
## Fluxo de Trabalho de Detecção
### Fase 1 — Normalizar o alvo
A ferramenta:
1. Adiciona um esquema `http` ou `https` padrão se estiver ausente.
2. Normaliza o caminho de instalação do WordPress.
3. Rejeita esquemas de URL não suportados e credenciais embutidas.
4. Aplica políticas de redirecionamento, proxy, TLS e tempo limite.
### Fase 2 — Identificar WordPress
O scanner verifica:
- referências a `wp-content/`.
- referências a `wp-includes/`.
- metadados do gerador WordPress.
- links de descoberta da API REST.
- estrutura do índice REST do WordPress.
- o namespace `wp/v2`.
- impressões digitais opcionais de feed e `readme.html`.
### Fase 3 — Determinar a versão
Evidências de versão podem vir de:
- metadados do gerador HTML.
- metadados do gerador de feed.
- strings de consulta de ativos principais do WordPress.
- cabeçalhos do gerador HTTP.
- `readme.html`.
- um arquivo local `wp-includes/version.php`.
As evidências são pontuadas e reconciliadas. Indicadores conflitantes de versão remota diminuem a confiança.
### Fase 4 — Verificar exposição de rota batch
O scanner tenta descobrir `/batch/v1` através de:```text
/?rest_route=/
/wp-json/
A rota pode ser tratada usando uma das seguintes:```text /?rest_route=/batch/v1 /wp-json/batch/v1
### Phase 5 — Sonda segura de confusão de rota
A sonda segura contém:
1. Um caminho interno deliberadamente malformado.
2. Uma requisição a um ID de post inválido com um `GET` público aninhado inofensivo.
3. Uma requisição seguinte `/batch/v1`.
Um servidor vulnerável retorna uma resposta externa `207 Multi-Status` na qual a requisição de post inválida é processada como uma requisição batch aninhada.
O detector reporta:```text
route-confusion-observed
quando vê:
parse_path_failed.207.responses aninhado mostrando que a requisição interna inofensiva foi executada.Um validador de SQLi não destrutivo deve enviar requisições emparelhadas que diferem apenas por uma condição Booleana constante:```text False control -> no deliberate database delay True test -> deliberate database delay
O validador deve: