wp2shell

Esecuzione remota di codice pre-autenticazione per WordPress 6.9.0–6.9.4 e 7.0.0–7.0.1.

Combina CVE-2026-63030 (SQLi da confusione delle route del batch) con CVE-2026-60137 (rientro del changeset del customizer) per ottenere la creazione di un amministratore senza autenticazione e l'esecuzione di comandi del sistema operativo. Nessun cracking delle password richiesto.

Un ringraziamento a hashkitten per la scoperta; leggi l'analisi tecnica completa di SLCyber qui.

La vulnerabilità

Il processore batch dell'API REST di WordPress (serve_batch_request_v1) ha un bug di indicizzazione off-by-one: quando wp_parse_url() fallisce su un percorso di sotto-richiesta, il WP_Error risultante viene aggiunto a $validation[] ma non a $matches[]. Questo desincronizza i due array — ogni richiesta successiva viene instradata tramite l'handler sbagliato.

Annidando un batch strutturato con cura all'interno di un altro batch, un attaccante può:

1. Instradare una richiesta validata dallo schema di un endpoint attraverso il callback di un endpoint completamente diverso
2. Iniettare SQL non sanificato tramite author__not_in (il cast stringa→array salta absint())
3. Usare UNION SELECT per avvelenare la cache degli oggetti di WordPress con falsi oggetti post
4. Attivare una pubblicazione automatica del changeset che eleva i privilegi, quindi rientrare nell'API REST con contesto admin

Una volta completata la configurazione (scoperta del prefisso delle tabelle e dell'ID admin), il payload di escalation si attiva in una singola richiesta HTTP — avvelenamento della cache, escalation dei privilegi e creazione dell'utente avvengono tutti lato server in un unico round-trip.

Come funziona la catena

HTTP POST /batch/v1
    │
    ▼
┌─ Outer Batch ───────────────────────────────────────────────────────┐
│                                                                     │
│  [0] ///                  → parse error, not added to $matches      │
│  [1] POST /wp/v2/posts    → $matches[0] (posts handler)             │
│  [2] POST /batch/v1       → $matches[1] (batch handler)             │
│                                                                     │
│  Desync: request[1] dispatched via $matches[1]                      │
│          POST /wp/v2/posts body interpreted as batch → inner fires  │
│                                                                     │
└──────────────────────────────────────┬──────────────────────────────┘
                                       │
    ┌──────────────────────────────────┘
    ▼
┌─ Inner Batch ───────────────────────────────────────────────────────┐
│                                                                     │
│  [0] ///                            → parse error (desync)          │
│  [1] GET  /wp/v2/widgets?UNION...   → dispatched by posts handler   │
│          ▲ WP_Query fires UNION, poisons object cache               │
│          ▲ the_content renders [embed] → oEmbed → hierarchy Loop 1  │
│              → changeset published → admin context set              │
│              → nav_menu_item UPDATE → hierarchy Loop 2              │
│                  → parse_request → REST re-entry ─────────────┐     │
│                                                               │     │
│  [2] GET  /wp/v2/posts              (categories handler)      │     │
│  [3] GET  /wp/v2/categories         (users handler)           │     │
│  [4] POST /wp/v2/users  {body}  ◄── re-entry with admin ──────┘     │
│          ▲ desync aligns this with users handler                    │
│          ▲ admin context → user created → die()                     │
│  [5] POST /wp/v2/users  {}          (desync spacer)                 │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

Avvelenamento della cache (7 post falsi tramite UNION):

• Un post trigger con uno shortcode [embed] nel suo contenuto
• Un post changeset (customize_changeset, stato future, data nel passato)
• Un partner del loop esterno (parent=changeset, che crea Loop 1)
• Un target oEmbed (ID dinamico anti-ricorsione, parent=changeset, contenuto vuoto)
• Un post di voce di menu (avvelenato come post_type=nav_menu_item per il controllo is_nav_menu_item)
• Un post di rientro (post_type=request, post_status=parse, parent=inner)
• Un partner del loop interno (parent=re-entry, che crea Loop 2)

Flusso di esecuzione:

1. UNION avvelena la cache degli oggetti con tutti e 7 i post falsi
2. L'handler dei post renderizza il contenuto del post trigger → lo shortcode [embed] si attiva
3. La ricerca nella cache oEmbed trova un post di supporto con contenuto vuoto → viene eseguito il fallthrough a wp_update_post
4. wp_update_post legge il changeset in cache (parent=outer) → il controllo di gerarchia rileva Loop 1
5. La correzione scrive il changeset nel DB con stato future → conversione automatica in publish
6. _wp_customize_publish_changeset si attiva → wp_set_current_user(admin_id) → contesto admin attivo
7. Il changeset elabora nav_menu_item[real_id] — la cache dice type=nav_menu_item → percorso UPDATE
8. object_id risolve un post in cache con post_parent=re-entry → wp_update_post sul post reale
9. Il controllo di gerarchia ($post_id non zero) rileva Loop 2 (re-entry ↔ inner)
10. La correzione chiama wp_update_post(re-entry) → scrive type=request, status=parse nel DB
11. wp_transition_post_status attiva do_action("parse_request") → rest_api_loaded() → serve_request()
12. L'API REST rientra e rielabora l'intero batch con privilegi di amministratore
13. POST /wp/v2/users in coda riesce → amministratore creato → die()

Una variabile di sessione MySQL anti-ricorsione (@_wp2s) garantisce che la catena si attivi esattamente una volta e non vada in loop.

Funzionalità

• Tre modalità di estrazione con rilevamento automatico: UNION (1 richiesta/valore), basata su errori tramite EXTRACTVALUE (~30 caratteri/richiesta), ricerca binaria boolean-blind (~7 richieste/carattere)
• RCE pre-auth completa — nessuna credenziale, nessun cracking, l'escalation si attiva in un singolo round-trip
• Auto-scoperta — prefisso delle tabelle tramite INFORMATION_SCHEMA, ID utente admin tramite meta delle capability
• Post-exploitation — webshell come plugin con autenticazione tramite token, shell interattiva con monitoraggio della CWD, lettura/scrittura file
• Modalità di pulizia — --cleanup elimina l'utente creato e rimuove la webshell all'uscita
• Zero dipendenze — solo stdlib, file singolo, funziona su Python 3.8+

Installazione

git clone https://github.com/Crypto-Cat/wp2shell.git
cd wp2shell
chmod +x wp2shell.py

Niente pip install, niente virtualenv. È un singolo file.

Utilizzo

Verifica se un target è vulnerabile

# Passive boolean oracle test
python3 wp2shell.py check http://target.com

# Also confirm with timing and UNION
python3 wp2shell.py check http://target.com --confirm-timing --confirm-union

Estrazione dei dati

# Auto-selects fastest technique (UNION > error > blind)
python3 wp2shell.py read http://target.com --preset users
python3 wp2shell.py read http://target.com --preset secrets
python3 wp2shell.py read http://target.com --query "SELECT @@version"

# Force a specific technique
python3 wp2shell.py read http://target.com --technique blind --preset users

# Auto-discover table prefix
python3 wp2shell.py read http://target.com --auto-prefix --preset users

Sfruttamento completo