Rilevatore PoC e validatore sicuro per la catena di vulnerabilità WP2Shell di WordPress: CVE-2026-63030 (confusione batch-route REST) + CVE-2026-60137 (iniezione SQL author__not_in). Solo per test di sicurezza autorizzati.
Copertura CVE: CVE-2026-63030 e CVE-2026-60137 Uso previsto: Solo test di sicurezza autorizzati, validazione difensiva e lab locali usa e getta
WP2Shell è una catena di vulnerabilità del core di WordPress che combina un bug di confusione batch-route dell'API REST pre-autenticazione (CVE-2026-63030) con una primitiva di SQL injection in WP_Query author__not_in (CVE-2026-60137). Questo repository fornisce uno scanner proof-of-concept Python e un validatore sicuro, così i difensori possono identificare le installazioni WordPress vulnerabili, confermare il comportamento vulnerabile in un laboratorio isolato e verificare la correzione — senza dover estrarre dati o ottenere esecuzione di codice.
Questo progetto identifica le installazioni WordPress e valida le due primitive di vulnerabilità associate alla catena di vulnerabilità del core di WordPress WP2Shell:
WP_Query::author__not_in, che può causare SQL injection quando input controllato dall'attaccante raggiunge il parametro.Quando entrambe le condizioni sono presenti, una richiesta non autenticata può raggiungere la costruzione SQL vulnerabile attraverso l'endpoint batch dell'API REST di WordPress. Gli advisory pubblici descrivono l'impatto combinato come potenzialmente in grado di portare all'esecuzione remota di codice.
Questo repository dovrebbe essere usato solo su sistemi di tua proprietà o su cui sei esplicitamente autorizzato a eseguire test. Preferisci un laboratorio Docker isolato o una macchina virtuale vincolata a 127.0.0.1.
Il file sorgente corrente contiene funzionalità che modificano lo stato, inclusi tentativi di estrazione di dati dal database, tentativi di scrittura di file, flussi di autenticazione, creazione di amministratori, caricamento di plugin ed esecuzione di comandi.
Le release interessate di WordPress possono perdere l'allineamento tra gli array interni usati per tracciare:
Quando un membro batch malformato viene accettato in un array interno ma non in un altro, le richieste successive possono essere associate all'handler sbagliato. Una richiesta può quindi essere validata come una route ma eseguita usando il callback di un'altra route.
Impatto sulla sicurezza:
author__not_inL'implementazione di WP_Query interessata non normalizza in modo coerente author__not_in prima di usarlo per costruire una condizione SQL NOT IN (...).
Il parametro normalmente si aspetta un elenco di ID autore interi. Se una stringa scalare raggiunge la costruzione vulnerabile della query senza la prevista validazione dello schema REST, una struttura SQL non sicura può arrivare fino alla query del database.
Impatto sulla sicurezza:
| Ramo WordPress | Interessate | Release corretta |
|---|---|---|
| 6.8.x | Solo CVE-2026-60137: 6.8.0–6.8.5 | 6.8.6 |
| 6.9.x | Entrambi i problemi: 6.9.0–6.9.4 | 6.9.5 |
| 7.0.x | Entrambi i problemi: 7.0.0–7.0.1 | 7.0.2 |
| 7.1 prerelease | Beta 1 vulnerabile | Beta 2 |
| Precedenti alla 6.8 | Non interessate da queste due CVE | N/A |
WordPress ha rilasciato correzioni il 17 luglio 2026 e ha abilitato gli aggiornamenti automatici forzati per le installazioni interessate a causa della gravità.
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
Il rilevatore dovrebbe fermarsi dopo aver confermato le primitive di route-confusion e SQL-injection. Non ha bisogno di estrarre dati o eseguire comandi per stabilire che un'installazione interessata è vulnerabile.
---
## Workflow di rilevamento
### Fase 1 — Normalizza il target
Lo strumento:
1. Aggiunge uno schema `http` o `https` predefinito se mancante.
2. Normalizza il percorso di installazione di WordPress.
3. Rifiuta schemi URL non supportati e credenziali incorporate.
4. Applica le policy di redirect, proxy, TLS e timeout.
### Fase 2 — Identifica WordPress
Lo scanner verifica la presenza di:
- riferimenti a `wp-content/`.
- riferimenti a `wp-includes/`.
- metadati del generatore WordPress.
- link di scoperta dell'API REST.
- struttura dell'indice REST di WordPress.
- il namespace `wp/v2`.
- fingerprint opzionali del feed e di `readme.html`.
### Fase 3 — Determina la versione
Le prove della versione possono provenire da:
- metadati del generatore HTML.
- metadati del generatore del feed.
- stringhe di query delle risorse core di WordPress.
- header HTTP del generatore.
- `readme.html`.
- un file locale `wp-includes/version.php`.
Le prove vengono valutate e riconciliate. Indicatori di versione remoti contrastanti riducono la confidenza.
### Fase 4 — Controlla l'esposizione della route batch
Lo scanner tenta di scoprire `/batch/v1` tramite:```text
/?rest_route=/
/wp-json/
Il percorso può essere affrontato utilizzando uno dei due:```text /?rest_route=/batch/v1 /wp-json/batch/v1
### Fase 5 — Sonda sicura di confusione di percorso
La sonda sicura contiene:
1. Un percorso interno volutamente malformato.
2. Una richiesta a un ID di post non valido con una `GET` pubblica annidata innocua.
3. Una richiesta successiva `/batch/v1`.
Un server vulnerabile restituisce una risposta esterna `207 Multi-Status` in cui la richiesta di post non valida viene elaborata come una richiesta batch annidata.
Il rilevatore segnala:```text
route-confusion-observed
quando vede:
parse_path_failed.207.responses annidato che mostra che la richiesta interna innocua è stata eseguita.