Il cuore di WordPress, eseguito da chi non ha fatto login: la catena WP2Shell

Perché questa riguarda quasi tutti

Non è l'attacco a un singolo prodotto di nicchia: è una falla nel nucleo della piattaforma su cui gira una quota enorme del web pubblico. In Italia significa una parte consistente dei siti di piccole e medie imprese, testate locali, studi professionali, e-commerce e portali di enti minori. Quando il difetto è nel core e non in un plugin di terze parti, la superficie esposta non è una lista di aziende: è "chiunque pubblichi su WordPress e non abbia ancora aggiornato".

Il 17 luglio 2026 sono state divulgate due vulnerabilità di WordPress Core. Prese singolarmente sono serie; concatenate diventano un grimaldello che apre l'esecuzione di codice da remoto senza bisogno di alcun login. I ricercatori hanno chiamato la catena WP2Shell.

1. 17 luglio 2026
   Divulgazione

   Rese pubbliche CVE-2026-60137 e CVE-2026-63030, con le patch.

2. Entro pochi giorni
   exploitation: active

   Sfruttamento in-the-wild confermato da più vendor; PoC pubblici in circolazione.

3. 21 luglio 2026
   Catalogo KEV

   CISA aggiunge CVE-2026-60137 alle vulnerabilità note sfruttate.

Le due falle, e perché insieme sono peggio

La prima, CVE-2026-60137, è una SQL injection nel cuore delle query di WordPress, WP_Query: nasce dalla sanificazione errata del parametro author__not_in. Da sola, su WordPress dalla 6.8.0 alla 6.8.5, permette di manipolare le interrogazioni al database — leggere dati che non dovrebbero essere accessibili, in certe configurazioni alterarli.

La seconda, CVE-2026-63030, è una confusione nelle rotte batch della REST API: una richiesta costruita ad arte viene interpretata in modo diverso da come chi ha scritto il controllo di accesso si aspettava. È il tipo di difetto che, preso da solo, sembra teorico; è quando lo si usa come leva su un altro che diventa il pezzo mancante.

Messe in fila, le due trasformano una lettura non autorizzata del database in esecuzione di codice su un'installazione WordPress di default, e lo fanno senza autenticazione. È il punto che porta la catena alla massima priorità: nessun account, nessun token, solo la capacità di raggiungere il sito via rete.

1. 01
   Richiesta HTTP non autenticata

   l'attaccante raggiunge il sito, senza credenziali
2. 02
   CVE-2026-60137

   SQL injection in WP_Query via author__not_in
3. 03
   CVE-2026-63030

   confusione delle rotte batch nella REST API
4. 04
   WP2Shell

   esecuzione di codice remoto su installazione di default

Cosa è confermato, e cosa no

Confermato: le CVE, la loro presenza nel core, le versioni patch e l'ingresso di CVE-2026-60137 nel catalogo CISA KEV il 21 luglio. Confermato anche che più società di sicurezza hanno osservato sfruttamento attivo entro pochi giorni dalla divulgazione, con proof-of-concept pubblici già in giro — la finestra fra "patch disponibile" e "attacco di massa" è stata cortissima.

Da dichiarare come incerto: non c'è un singolo gruppo attribuito. Lo scenario coerente con i dati è lo sfruttamento opportunistico di massa — scanner automatici che colpiscono tutto ciò che risponde, tipico quando un PoC per una piattaforma diffusissima diventa pubblico — non una campagnia mirata a un bersaglio. Le cifre esatte sui siti compromessi, in questa fase, non sono verificabili: vanno trattate come stime, non come conteggi.

Cosa fare, adesso

Le patch esistono: WordPress 6.8.6, 6.9.5 e 7.0.2. Vista la gravità, WordPress ha fatto una cosa che fa di rado — forzare l'aggiornamento automatico su tutte le installazioni supportate. Questo copre la maggioranza dei siti in modo trasparente, ma non tutti: chi ha disattivato gli auto-update, chi gira su un fork o su una versione fuori supporto, chi ha un'installazione "congelata" da un hosting che non applica i core update, resta esposto.

L'azione è una sola e non rinviabile: verificare la versione del proprio WordPress e, se non è tra quelle patchate, aggiornare subito. Poi controllare che l'auto-update sia davvero andato a buon fine — non darlo per scontato — e, sui siti che potrebbero essere stati raggiunti prima della patch, cercare segni di compromissione: utenti amministrativi non riconosciuti, file inattesi sotto la web root, attività anomala nei log della REST API. Con una catena pre-auth già sfruttata e con PoC pubblici, la domanda non è se qualcuno proverà, ma se ha già provato.