WordPress, la RCE CVE-2026-63030: cosa controllare sul tuo sito

Il 17 luglio 2026 WordPress ha pubblicato la versione 7.0.2, insieme alle 6.9.5 e 6.8.6 per i rami più vecchi. Non è stato un rilascio ordinario: chiude due vulnerabilità che, sfruttate una dopo l’altra, permettono a chiunque — senza login, senza account, senza niente — di eseguire codice sul server che ospita il sito.

Quattro giorni dopo, il 21 luglio, la CISA americana ha aggiunto entrambe al catalogo delle vulnerabilità sfruttate attivamente, con scadenza di rimedio al 24 luglio per la prima e al 4 agosto per la seconda. Non è un rischio teorico: qualcuno le sta usando.

Le due falle, in ordine

CVE-2026-60137 è una SQL injection. Il parametro author__not_in di WP_Query non viene sanificato come dovrebbe: se un plugin o un tema ci passa dentro un valore che arriva dall’esterno, quel valore finisce nella query. Riguarda le versioni da 6.8.0 a 6.8.5, da 6.9.0 a 6.9.4 e da 7.0.0 a 7.0.1. Da sola ha un punteggio medio (5.9 secondo WPScan) proprio perché serve un plugin o un tema che la renda raggiungibile.

CVE-2026-63030 è quella che cambia tutto. È una route confusion nell’endpoint batch delle REST API (/wp-json/batch/v1): l’endpoint può finire per far gestire una richiesta all’handler sbagliato. Riguarda solo i rami più recenti — dalla 6.9.0 alla 6.9.4 e dalla 7.0.0 alla 7.0.1 — ed è classificata critica, CVSS 9.8 sul database NVD.

Il problema è la somma. La route confusion rende la SQL injection raggiungibile da fuori, senza autenticazione, su un’installazione WordPress appena scaricata. È questo che trasforma due bug di gravità diversa in una presa di controllo completa del sito.

Chi ha trovato la catena è Adam Kues di Assetnote / Searchlight Cyber, ed è citato nell’advisory ufficiale.

Chi è esposto e chi no

• Sotto la 6.8: non interessate.
• 6.8.x: solo la SQL injection. Si risolve con la 6.8.6.
• 6.9.x: entrambe. Si risolve con la 6.9.5.
• 7.0.x: entrambe. Si risolve con la 7.0.2.

Vista la gravità, il team di WordPress.org ha forzato l’aggiornamento automatico sui siti che giravano su versioni vulnerabili. È una buona notizia, ma non è una garanzia: l’auto-update non parte se qualcuno ha messo AUTOMATIC_UPDATER_DISABLED in wp-config.php, se WP_AUTO_UPDATE_CORE è a false, se i permessi sui file non lasciano scrivere a PHP, o se l’hosting gestito tiene la versione bloccata per conto suo.

Quindi la prima cosa da fare non è aggiornare: è guardare che versione hai. Dalla bacheca di WordPress, Aggiornamenti; da riga di comando, wp core version. Se il numero non è 7.0.2, 6.9.5, 6.8.6 o superiore, il sito è ancora aperto.

Aggiornare non basta, se sei rimasto scoperto

Questa è la parte che di solito nessuno dice al cliente. L’aggiornamento chiude la porta. Non annulla quello che è successo mentre era aperta.

Se il sito girava su una versione vulnerabile ed era raggiungibile da internet nelle settimane intorno a metà luglio, dopo aver aggiornato vale la pena controllare qualche cosa:

• Gli utenti amministratori. Un account in più, magari con un nome che assomiglia a uno vero, è il modo più comune per tenersi la chiave anche dopo la patch.
• I file modificati di recente dentro wp-content/, in particolare in uploads/: lì dentro non deve esserci nulla con estensione .php.
• Le attività pianificate (wp cron event list): un evento che non riconosci merita due minuti di attenzione.
• I log del web server, cercando le richieste all’endpoint coinvolto:

grep 'wp-json/batch/v1' /var/log/nginx/access.log

Su un sito normale quell’endpoint viene chiamato pochissimo, e quasi sempre dall’editor a blocchi di un utente loggato. Una raffica di POST da un IP che non conosci, in un periodo in cui il sito era su una versione vulnerabile, è esattamente il tipo di riga che vale la pena tenere.

Se qualcosa non torna, la strada onesta è il ripristino da un backup precedente all’esposizione, seguito dall’aggiornamento — non la caccia al file infetto. Pulire un sito compromesso a mano è un lavoro che riesce raramente al primo colpo.

Cosa lasciare acceso, d’ora in poi

Il motivo per cui migliaia di siti si sono chiusi da soli in questa vicenda è che avevano gli aggiornamenti automatici del core attivi. Vale la pena dirlo perché la tentazione opposta è comune: si disattivano gli auto-update dopo che un aggiornamento ha rotto qualcosa, e poi ci si dimentica di averlo fatto.

La versione ragionevole è: aggiornamenti automatici accesi per il core, che è il pezzo che riceve patch di sicurezza come questa; aggiornamenti controllati per plugin e temi, dove un rilascio sbagliato fa più danni. E un backup che parte prima dell’aggiornamento, così se qualcosa si rompe si torna indietro in cinque minuti invece che in due giorni.

Le fonti

Tutti i dati qui sopra vengono dalle fonti primarie, non da riassunti:

• WordPress 7.0.2 Security Release — l’annuncio ufficiale
• GHSA-ff9f-jf42-662q — l’advisory di CVE-2026-63030
• CVE-2026-63030 e CVE-2026-60137 su NVD
• CISA Known Exploited Vulnerabilities Catalog

Se hai un sito WordPress e non sai su che versione gira, quella è la domanda da farsi oggi, non la prossima volta.