WordPress 7.0.2: la falla RCE che forza l'update

Il 17 luglio 2026 il team di sicurezza ha pubblicato WordPress 7.0.2 per chiudere due vulnerabilità collegate nel core. La più grave, CVE-2026-63030, permette a un attaccante senza account di arrivare all'esecuzione remota di codice. WordPress ha classificato il caso nella fascia di priorità più alta e ha attivato gli aggiornamenti automatici forzati sui siti coinvolti.

L'update riduce la finestra di esposizione, ma serve una verifica. Un aggiornamento in background può fallire e la patch non cancella le tracce di un attacco avvenuto prima dell'installazione.

WordPress 7.0.2: cosa è successo

La nota ufficiale di WordPress descrive una SQL injection e una confusione delle route nell'endpoint batch della REST API. I due difetti hanno identificativi separati:

• CVE-2026-60137 riguarda il parametro author__not_in di WP_Query. Un valore non filtrato può alterare la query inviata al database.
• CVE-2026-63030 riguarda la gestione delle richieste batch nella REST API. Combinata con la SQL injection, apre una strada verso la Remote Code Execution.

Il security advisory del progetto WordPress classifica la seconda vulnerabilità come critica. Non servono credenziali né un clic dell'amministratore. Secondo l'analisi tecnica pubblicata da Cloudflare, il percorso verso la RCE interessa WordPress 6.9 e versioni successive quando il sito non usa una cache persistente degli oggetti.

Una cache Redis o Memcached non equivale a una correzione. Può interrompere una particolare catena di exploit, ma lascia nel core il codice vulnerabile. La patch resta necessaria su ogni installazione coinvolta.

Quali versioni WordPress sono vulnerabili

Il ramo installato determina sia l'esposizione sia la versione corretta da applicare.

La distinzione conta. Un sito su WordPress 6.8 non rientra nella catena RCE descritta da CVE-2026-63030, ma resta esposto alla SQL injection e deve passare alla 6.8.6. WordPress 6.9 e 7.0 richiedono le rispettive release corrette.

Se hai seguito il rilascio di WordPress 7.0 Armstrong, controlla con attenzione i siti aggiornati nelle ultime settimane: le versioni 7.0.0 e 7.0.1 rientrano nel perimetro critico.

Perché WordPress ha forzato l'aggiornamento

WordPress usa gli aggiornamenti di sicurezza in background per distribuire correzioni urgenti senza aspettare l'intervento di ogni amministratore. Per WordPress 7.0.2, il team ha abilitato un push forzato a causa della gravità e della facilità di automazione dell'attacco.

La decisione protegge molti siti nelle prime ore dopo la divulgazione. Non garantisce che ciascuna installazione abbia ricevuto la patch. Permessi errati sui file, spazio esaurito, errori PHP o configurazioni che bloccano le richieste del sistema possono interrompere l'operazione. Anche un sito di staging dimenticato può restare online con una versione vulnerabile.

Controlla il numero di versione nella schermata Bacheca > Aggiornamenti. Se usi WP-CLI, bastano due comandi:

wp core version
wp core check-update

Il primo deve mostrare 7.0.2, 6.9.5 oppure 6.8.6, in base al ramo. Se compare una versione precedente, avvia l'aggiornamento e verifica che WordPress lo completi senza errori:

wp core update
wp core verify-checksums

verify-checksums confronta i file del core con quelli ufficiali della stessa release. Un risultato pulito conferma l'integrità dei file standard, ma non analizza plugin, temi, database o directory degli upload.

Aggiornare non basta se il sito era già esposto

Una patch impedisce nuove richieste attraverso il percorso vulnerabile. Non rimuove account creati da un attaccante, file PHP caricati negli upload o modifiche al database eseguite prima dell'update.

Al 18 luglio, il record NVD di CVE-2026-63030 riportava assenza di sfruttamento confermato nei dati CISA associati. La vulnerabilità è però automatizzabile e il suo impatto tecnico può essere totale. Conviene trattare i siti rimasti sulle versioni vulnerabili come sistemi da controllare, senza dichiararli compromessi in assenza di prove.

Parti dagli amministratori e dai componenti attivi:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list --status=active

Confronta gli account con il tuo elenco autorizzato. Cerca plugin che non riconosci, amministratori creati dopo il 17 luglio e file PHP recenti in wp-content/uploads/. Nei log del server, controlla le richieste dirette all'endpoint batch:

grep -E '(/wp-json/batch/v1|rest_route=/batch/v1)' access.log*

Una richiesta all'endpoint non prova da sola un attacco. IP insoliti, molte richieste ravvicinate, parametri anomali e modifiche ai file nella stessa finestra temporale meritano un'analisi più approfondita. Conserva i log e una copia del sito prima di ripristinare o reinstallare componenti.

WAF e hosting: protezione mentre arriva la patch

Cloudflare ha distribuito il 17 luglio due regole WAF dedicate, una per la SQL injection e una per la RCE. Le regole proteggono il traffico che passa attraverso il suo proxy, compresi gli account gratuiti. Cloudflare raccomanda comunque di aggiornare WordPress: il WAF filtra richieste note, mentre WordPress 7.0.2 corregge il codice che le rende pericolose.

Lo stesso principio vale per ModSecurity e altri firewall applicativi. Una regola offre tempo al gestore del sito, ma può subire esclusioni, override o varianti dell'attacco. Controlla che l'azione prevista sia Block e consulta gli eventi di sicurezza durante la fase di aggiornamento.

Per chi gestisce un sito aziendale, il servizio hosting dovrebbe fornire almeno log accessibili, backup verificabili e aggiornamenti del core monitorati. Sui nostri piani di hosting condiviso puoi chiedere al supporto di verificare versione WordPress, stato dell'aggiornamento e anomalie nei log senza affidarti al solo messaggio mostrato in bacheca.

Cosa fare

Controlla la versione di ogni sito WordPress, inclusi staging e vecchi sottodomini. Porta i rami coinvolti alla versione 6.8.6, 6.9.5 o WordPress 7.0.2, poi verifica checksum, account amministrativi e richieste alla REST API.

La distribuzione forzata riduce il numero di installazioni esposte. Il controllo dopo l'update chiude il lavoro: conferma che la patch sia arrivata e che nessuno abbia usato la vulnerabilità prima di te.