// 1 CRITICAL · 5 ZERO-DAY · 8 CVE · 5 EXPLOIT NELLE ULTIME 24H
Il gruppo HackerHood ha replicato in laboratorio la catena wp2shell su WordPress 6.9.1. CISA ha già inserito entrambe le CVE nel KEV con due date di patching

Il 23 luglio 2026 il gruppo HackerHood ha pubblicato la dimostrazione tecnica completa della vulnerabilità wp2shell su WordPress 6.9.1, ottenendo esecuzione remota di codice pre-autenticazione in un ambiente di laboratorio controllato. La stessa catena di attacco è già segnalata come exploitation attiva da CISA, che ha imposto due date distinte di remediation obbligatoria per le due CVE coinvolte.

L'analisi si inserisce in un momento di criticità per la governance del patching WordPress: la dimostrazione prova che l'intero flusso, dalla richiesta HTTP iniziale alla shell interattiva, richiede pochi secondi e nessuna interazione manuale da parte dell'attaccante.

Punti chiave
  • Due CVE concatenate nel core WordPress: CVE-2026-60137 (SQL injection in WP_Query) e CVE-2026-63030 (route confusion nell'endpoint REST /batch/v1), con CISA KEV attivo per entrambe
  • Il meccanismo root cause risiede nel disallineamento tra array paralleli di match e validazione quando wp_parse_url() fallisce la normalizzazione di un path di sotto-richiesta
  • La catena di laboratorio include creazione automatica di utente amministratore, autenticazione automatica, deploy di webshell come plugin fittizio ed esecuzione di comandi di sistema su stack Windows/XAMPP
  • CISA ha fissato la due date 07/24/2026 per CVE-2026-63030 e 08/04/2026 per CVE-2026-60137, con SSVC che classifica la prima come exploitation:active, automatable:yes, technicalImpact:total

Il meccanismo: come due vulnerabilità distinte si concatenano in RCE

Il nucleo tecnico è un disallineamento strutturale nella gestione batch dell'endpoint REST /batch/v1 di WordPress. La funzione serve_batch_request_v1() gestisce due array paralleli indicizzati sullo stesso offset: uno per i match di rotta, l'altro per i risultati di validazione. Quando wp_parse_url() fallisce la normalizzazione di un path di sotto-richiesta, l'elemento viene aggiunto all'array dei risultati di validazione ma non a quello dei match.

Questa confusione di rotta permette a una richiesta malevola di "ereditare" la validazione di richieste precedenti nella stessa batch. La conseguenza immediata è l'accesso a parametri protetti che dovrebbero essere filtrati, in particolare author__not_in di WP_Query, dove si innesca la SQL injection documentata come CVE-2026-60137.

La catena dimostrata in laboratorio procede in sequenza: richiesta non autenticata all'endpoint batch, route confusion, SQL injection, creazione di un utente amministratore con credenziali generate automaticamente, autenticazione automatica sotto quell'utente, caricamento di un plugin contenente una webshell, esecuzione di comandi di sistema con i privilegi del processo web. Il tutto avviene senza interazione manuale e in pochi secondi, come documentato negli screenshot terminali pubblicati.

"da una richiesta HTTP non autenticata si arriva, in pochi secondi e senza alcuna interazione manuale, all'esecuzione di codice con i privilegi del processo web" — HackerHood/Red Hot Cyber

Le versioni coinvolte e le patch d'emergenza

Secondo il record NVD per CVE-2026-63030, le versioni vulnerabili sono quelle dalla 6.9 alla 6.9.5 esclusa, e dalla 7.0 alla 7.0.2 esclusa. L'articolo di HackerHood conferma che il PoC pubblicato su GitHub (repository Icex0/wp2shell-poc) risulta funzionante sul range 6.9.0-6.9.4, con il target di laboratorio specifico sulla versione 6.9.1.

Le release patchate d'emergenza sono la 7.0.2, la 6.9.5 e la 6.8.6. La dimostrazione è stata condotta su un'installazione WordPress con stack XAMPP/Windows, con adattamento del PoC originale sviluppato per ambienti Linux.

Il record NVD per CVE-2026-60137 riporta un CVSS 3.1 di 5.9 (MEDIUM), con vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N. Il record per CVE-2026-63030 riporta invece il vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, indicativo di severità critica, ma non esplicita il punteggio numerico completo nel dossier disponibile.

Il contesto CISA: exploitation attiva e date obbligatorie

Entrambe le CVE sono presenti nel Catalogo delle Vulnerabilità Sfruttate Conosciute (KEV) di CISA, con profili di rischio differenziati. Per CVE-2026-63030, il contributo CISA-ADP nel record NVD include l'analisi SSVC con exploitation:active, automatable:yes, technicalImpact:total. La due date imposta da CISA è il 24 luglio 2026.

Per CVE-2026-60137, il KEV riporta required action con due date fissata al 4 agosto 2026. La discrepanza temporale riflette la valutazione diversa dell'agencies sulla componente route confusion rispetto alla SQL injection isolata.

WPScan, citato come contributor nei record NVD, conferma il rilevamento delle due CVE concatenate nella versione 6.9.1, secondo quanto riportato nell'articolo di HackerHood.

Cosa fare adesso

  • Verificare la versione WordPress in uso: le installazioni sulle serie 6.9.x prima della 6.9.5 e 7.0.x prima della 7.0.2 sono vulnerabili secondo il record NVD
  • Applicare gli aggiornamenti d'emergenza rilasciati nelle versioni 7.0.2, 6.9.5 o 6.8.6, rispettando la due date CISA del 24 luglio 2026 per CVE-2026-63030
  • Controllare la presenza di account amministratore non riconosciuti creati in tempi recenti, data la capacità dimostrata di generazione automatica di utenti con privilegi elevati
  • Rivedere i log di accesso all'endpoint /wp-json/batch/v1 per richieste anomale che possano indicare tentativi di route confusion

Laboratorio e realtà: i limiti del dossier

La dimostrazione di HackerHood è esplicitamente contestualizzata come attività didattica in laboratorio isolato. Le citazioni dirette sottolineano che "tutte le attività descritte sono state condotte in un laboratorio isolato e controllato, su un'installazione WordPress dedicata e priva di dati reali, appositamente predisposta per l'analisi della vulnerabilità".

Non è confermato che la catena esposta corrisponda esattamente agli attacchi in-the-wild segnalati da CISA KEV. Il dossier non specifica la natura dei dati eventualmente esposti negli incidenti reali, né identifica gli operatori dietro l'exploitation attiva. Il claim editoriale di "500 milioni di siti potenzialmente vulnerabili" non è verificato indipendentemente e va letto come stima di impatto potenziale, non come conteggio di installazioni effettivamente a rischio.

Mancano inoltre dettagli sulla timeline di disclosure responsabile: il dossier non indica chi abbia scoperto originariamente la vulnerabilità, né la data di divulgazione al team di sicurezza WordPress.

Il valore della dimostrazione risiede nella prova concreta di automatizzabilità estrema. CISA ha già classificato l'exploit come automatable:yes; HackerHood ha fornito la verifica visiva che questa classificazione corrisponde a un attacco replicabile senza adattamenti significativi da una macchina all'altra. Per gli amministratori che ritardano gli aggiornamenti per compatibilità plugin, il margine di sicurezza si è ridotto drasticamente.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. redhotcyber.com
  2. nvd.nist.gov