Il 17 luglio 2026, Searchlight Cyber ha reso pubblica una falla nel core di WordPress che permette a chiunque, senza account e senza plugin particolari, di prendere il controllo completo di un sito. La vulnerabilità chiamata wp2shell permette l’esecuzione di codice arbitrario su una piattaforma che sostiene oltre 500 milioni di siti web in tutto il mondo.

wp2shell è possibile grazie a due vulnerabilità concatenate, tracciate rispettivamente come CVE-2026-63030, individuata da Adam Kues di Searchlight Cyber, e CVE-2026-60137, segnalata da un altro gruppo di ricercatori (TF1T, dtro e haongo). Ma come funziona nel dettaglio l’attacco?

WordPress offre un endpoint delle REST API (/wp-json/batch/v1) pensato per raggruppare più richieste in una sola chiamata, comodo per app e plugin che devono fare tante operazioni insieme. Il bug sta nel modo in cui WordPress smista queste richieste raggruppate: se una di esse ha un formato leggermente sbagliato, WordPress perde il conto di quale richiesta va abbinata a quale controllo di sicurezza, e finisce per eseguirne una al posto di un’altra senza accorgersene. Questo tipo di vulnerabilità è conosciuto come route confusion ed è il primo tassello per compromettere il server WordPress.

Questo primo problema da solo permetterebbe infatti “solo” di far eseguire una richiesta al posto di un’altra. Diventa pericoloso però perché dietro c’è un secondo bug: uno dei campi che normalmente WordPress controlla con attenzione (un parametro che serve a escludere alcuni autori da una ricerca) finisce, grazie al primo errore, per non essere controllato affatto. E quel campo viene usato da WP_Query per costruire una query verso il database senza le protezioni giuste, aprendo la porta a una classica SQL injection: un attaccante può scrivere un valore che il database interpreta come comando invece che come semplice dato.

Da soli, questi due bug sarebbero gestibili, ma insieme, permettono di leggere dati sensibili dal database (comprese le password cifrate degli amministratori), creare un account amministratore dal nulla, e infine caricare un plugin che esegue comandi sul server: in pratica, una Remote Code Execution (RCE) non autenticata.

Per il primo giorno, Searchlight ha reso pubblico solo uno strumento per verificare se un sito è vulnerabile, senza spiegare come sfruttarlo davvero, proprio per dare tempo di installare la patch. Nel giro di poco tempo però su una repository GitHub è spuntato un PoC pubblico e funzionante che spiega in che modo replicare l’intero attacco. Nell’immagine sottostante vediamo un esempio di flusso di attacco che porta da wp2shell a una shell sul sistema compromesso.

Il PoC mostra come, attraverso la SQL injection, sia possibile creare un utente amministratore tramite una POST a /wp/v2/users. Un login come quell’admin generato e l’upload di un plugin bastano poi per ottenere l’esecuzione di comandi. Tutti i passaggi che portano alla creazione dell’account admin restano pre-autenticazione. Solo l’ultimo, l’upload del plugin, richiede la sessione appena creata.

Sul sito wp2shell.com è possibile controllare se il proprio sito è vulnerabile. Abbiamo testato l’affidabilità di questo strumento lanciando l’exploit wp2shell direttamente contro il nostro sito miamammausalinux.org, e l’esito è stato corretto: non abbiamo ottenuto alcuna RCE. Per un risultato più accurato consigliamo comunque di usare il PoC pubblico in modalità check sul proprio sito, per verificare se l’exploit sia effettivamente sfruttabile o meno tramite python3 wp2shell.py check https://sito-target.

Comunque, non tutte le versioni di WordPress sono colpite allo stesso modo. Di seguito abbiamo inserito una tabella con la versione di WordPress e il rischio corrispondente:

Versione	Cosa rischia
Prima della 6.8	Nessun problema
6.8.0 – 6.8.5	Solo il bug del database (gravità media)
6.9.0 – 6.9.4 e 7.0.0 – 7.0.1	Entrambi i bug insieme, quindi il rischio massimo

Le correzioni sono già disponibili nelle versioni 7.0.2, 6.9.5 e 6.8.6, e WordPress ha spinto l’aggiornamento automatico su molte installazioni. Non tutte, però: chi gestisce un sito con aggiornamenti automatici disattivati, o pubblicato tramite un sistema di deploy personalizzato, deve controllare manualmente e aggiornare al più presto.

Se un aggiornamento immediato non è possibile, ci sono soluzioni tampone, da usare solo temporaneamente perché possono rompere funzionalità legittime: un plugin che blocchi l’accesso alle API di WordPress a chi non ha fatto login, oppure una regola sul proprio firewall applicativo (WAF) che blocchi l’endpoint incriminato. Chi usa già servizi come Cloudflare è parzialmente coperto, perché sono state pubblicate regole di protezione lo stesso giorno della scoperta.