Vulnerabilità WordPress 7.0.2: cosa è successo e perché l'assistenza fa la differenza

Il 17 luglio 2026 WordPress ha rilasciato le versioni 7.0.2, 6.9.5 e 6.8.6 per correggere due problemi di sicurezza nel core. Sui rami 6.9 e 7.0 vulnerabili, le falle potevano essere combinate fino a consentire il controllo completo del sito senza autenticazione. Nel bollettino ufficiale di WordPress, il team ha raccomandato l’aggiornamento immediato e annunciato l’attivazione degli aggiornamenti forzati per le versioni coinvolte. L’aggiornamento va comunque verificato: applicare una patch e controllare che il sito sia integro sono due attività diverse.

Che cosa è successo il 17 luglio 2026

WordPress 7.0.2 non è stato un aggiornamento ordinario. Il team ufficiale lo ha pubblicato come release di sicurezza per correggere una vulnerabilità critica e una di gravità elevata: CVE-2026-60137 e CVE-2026-63030. La prima riguardava il modo in cui WordPress costruiva una particolare interrogazione al database. La seconda interessava la gestione di richieste multiple tramite le REST API. Insieme, sui rami coinvolti, potevano permettere a una richiesta non autenticata di superare controlli che avrebbero dovuto bloccarla. Tradotto: non era necessario possedere una password per tentare l’attacco. La catena resa pubblica poteva arrivare alla creazione di un amministratore abusivo e, da lì, all’esecuzione di codice sul server. In pratica, un possibile controllo completo del sito. La parte più istruttiva non è soltanto la gravità tecnica. È la velocità. Patchstack riferisce di aver osservato i primi tentativi circa 90 minuti dopo il rilascio della correzione. Nei giorni successivi dichiara di aver bloccato oltre 65.000 tentativi provenienti da più di 1.500 indirizzi IP contro siti ancora vulnerabili. Una falla, quindi, non resta a lungo una notizia per addetti ai lavori. Può diventare una campagna automatizzata mentre molte aziende non sanno ancora che esiste.

Quali versioni di WordPress erano coinvolte?

È importante leggere bene l’ultima riga. «Non coinvolto da queste CVE» non significa «sicuro». Una versione vecchia può avere altri problemi noti, non ricevere più correzioni o essere incompatibile con plugin e temi aggiornati.

Le due vulnerabilità spiegate senza gergo

CVE-2026-60137: dati non controllati dentro una query

WordPress riceve informazioni dal browser, le controlla e poi le usa per interrogare il database. In una particolare condizione, un valore poteva arrivare alla query senza essere normalizzato correttamente. È il presupposto di una SQL injection. Da sola, questa prima falla non equivaleva automaticamente alla conquista del sito: nel normale percorso delle REST API, altri controlli avrebbero dovuto impedire di inviare quel valore nel formato pericoloso.

CVE-2026-63030: il controllo applicato alla richiesta sbagliata

La seconda falla creava una confusione fra la richiesta da validare e la funzione incaricata di eseguirla. Immaginiamo un controllo documenti effettuato alla porta A e una persona che, per un errore nell’ordine della fila, viene poi fatta entrare dalla porta B: il controllo esiste, ma non resta collegato all’azione corretta. Combinando questa confusione con la prima vulnerabilità, un attaccante non autenticato poteva far arrivare al database un input che normalmente sarebbe stato rifiutato. È la catena, non una singola riga difettosa, a trasformare il problema in un rischio critico.

Perché l’aggiornamento automatico non chiude da solo il discorso

WordPress ha attivato aggiornamenti forzati per i siti sulle versioni interessate. È una misura importante, ma non è una ricevuta universale di avvenuta sicurezza. Un aggiornamento automatico può non completarsi per permessi errati, spazio insufficiente, configurazioni particolari o problemi del server. Inoltre, se un sito fosse stato raggiunto prima della patch, l’aggiornamento chiuderebbe la porta usata dall’attaccante ma non cancellerebbe automaticamente eventuali account, file o modifiche già introdotti. Per questo un intervento professionale comprende almeno tre momenti:

1. verificare versione e reale esposizione;
2. applicare o confermare la patch senza compromettere il funzionamento del sito;
3. cercare indicatori coerenti con una possibile compromissione.

La patch risolve la vulnerabilità. La verifica successiva serve a controllare che non vi siano segnali anomali.

Come wp2shell poteva portare al controllo del sito

Il nome wp2shell descrive il risultato della catena di attacco: partire da una richiesta web verso WordPress e arrivare alla possibilità di eseguire comandi sul sistema che ospita il sito. Non è il nome di un malware installato automaticamente e non significa che ogni sito WordPress sia stato compromesso. La sequenza resa nota dai ricercatori prevedeva più passaggi. La confusione nella gestione delle richieste batch consentiva di raggiungere la SQL injection senza essere autenticati. Attraverso la lettura di informazioni dal database, l’attaccante poteva ottenere elementi utili a costruire un nuovo accesso amministrativo. Un amministratore WordPress, a sua volta, può normalmente installare o modificare componenti PHP: da qui la possibilità di arrivare alla remote code execution, cioè all’esecuzione di codice sul server. Questa distinzione è importante per valutare correttamente il rischio:

• vulnerabile significa che il sito utilizza una versione esposta alla falla;
• attaccato significa che qualcuno ha provato a sfruttarla;
• compromesso significa che il tentativo ha avuto successo e ha prodotto accessi o modifiche non autorizzate.

Le tre condizioni non sono equivalenti. Tuttavia, quando esiste uno strumento di attacco pubblico e i tentativi sono già osservati su Internet, non è prudente limitarsi a correggere la versione e dichiarare concluso l’incidente.

Quali controlli fare dopo l’aggiornamento

I controlli devono essere proporzionati al sito, all’esposizione e ai dati disponibili. Un blog informativo e un e-commerce con ordini, pagamenti e dati personali non hanno lo stesso profilo di rischio. In entrambi i casi, però, alcuni segnali meritano attenzione.

Utenti amministratori sconosciuti

Bisogna confrontare gli account con privilegi elevati con l’elenco delle persone realmente autorizzate. Un nuovo amministratore non riconosciuto, soprattutto se creato nel periodo compreso fra la pubblicazione della falla e l’applicazione della patch, è un indicatore serio. Non è sufficiente eliminarlo: occorre capire come sia stato creato e quali azioni abbia eseguito.

Plugin, temi e file inattesi

Un componente che nessuno ricorda di aver installato, un plugin apparentemente legittimo ma collocato in una directory insolita o file PHP comparsi nelle cartelle di upload possono indicare persistenza. Vanno controllate anche le modifiche recenti ai plugin già presenti e ai cosiddetti must-use plugin, che non sempre sono visibili come i componenti ordinari nella bacheca.

Reindirizzamenti, pagine alterate ed errori insoliti

Gli attacchi a WordPress non producono sempre una pagina chiaramente vandalizzata. Possono inserire reindirizzamenti visibili soltanto da motori di ricerca o dispositivi specifici, contenuti spam nascosti, script esterni o nuove pagine create per intercettare traffico. Anche un improvviso aumento degli errori può essere un indizio, se coincide con modifiche non autorizzate.

Log e attività nel periodo di esposizione

Quando disponibili, i log del web server, del firewall e dell’applicazione aiutano a ricostruire le richieste ricevute e la cronologia delle modifiche. L’assenza di un’anomalia visibile nella bacheca non dimostra, da sola, che non ci siano stati tentativi o accessi. Per questo conservazione e analisi dei log fanno parte di una gestione matura della sicurezza.

Aggiornare subito, ma in modo controllato

“Aggiornare immediatamente” non significa fare clic senza preparazione su un sito che genera vendite o contatti. Un processo corretto combina rapidità e controllo. Prima si identifica il ramo WordPress installato e la versione corretta da applicare. Si verifica poi la disponibilità di un backup recente e realmente utilizzabile. Dopo l’aggiornamento si controllano almeno accesso, pagine principali, moduli, checkout, pagamenti, aree riservate e integrazioni determinanti per l’attività. Se emergono indicatori di compromissione, il lavoro cambia natura: non si tratta più soltanto di manutenzione, ma di risposta a un incidente. Può essere necessario isolare il sito, preservare i dati utili all’analisi, cambiare le credenziali, rigenerare chiavi e token, sostituire file alterati e verificare database, account, server e servizi collegati. Ripristinare un backup può essere parte della soluzione, ma soltanto se si conosce un punto certamente precedente alla compromissione. Ripristinare senza correggere la vulnerabilità o senza cambiare gli accessi coinvolti rischia di riportare online lo stesso problema.

Cosa fare se il tuo sito non è seguito da un servizio di assistenza

Per prima cosa, non affidarti alla sola impressione che «il sito funziona». Un sito compromesso può continuare ad apparire normale. Controlla la versione WordPress e verifica che il ramo sia almeno 7.0.2, 6.9.5 o 6.8.6. Prima di un aggiornamento manuale su un sito critico, esegui un backup completo e accertati che sia ripristinabile. Dopo la patch, controlla la presenza di amministratori sconosciuti, plugin inattesi e modifiche recenti non spiegate. Se il sito gestisce e-commerce, prenotazioni, dati personali o campagne pubblicitarie, evita un intervento alla cieca. L’urgenza non elimina la necessità di proteggere la continuità operativa.

Domande frequenti

Qual è la vulnerabilità corretta da WordPress 7.0.2?

WordPress 7.0.2 corregge due vulnerabilità, CVE-2026-60137 e CVE-2026-63030. Sui rami 6.9 e 7.0 vulnerabili potevano essere concatenate per superare i controlli delle REST API, raggiungere una SQL injection e arrivare al controllo completo del sito senza autenticazione.

WordPress 6.8 era vulnerabile?

Il ramo 6.8 era coinvolto dalla prima vulnerabilità, relativa alla query, ma non dalla confusione delle REST API introdotta nel ramo 6.9. La correzione per WordPress 6.8 è inclusa nella versione 6.8.6.

Le versioni precedenti a WordPress 6.8 sono sicure?

Il bollettino di sicurezza WordPress indica che le versioni precedenti alla 6.8 non erano coinvolte da queste due specifiche vulnerabilità. Ciò non rende sicura una versione obsoleta: possono esistere altre falle e può mancare il supporto necessario. La scelta corretta resta usare un ramo mantenuto e aggiornato.

Aggiornare WordPress è sufficiente?

L’aggiornamento chiude la vulnerabilità, ma non prova che il sito non sia stato raggiunto prima. In presenza di sfruttamento attivo occorre verificare almeno utenti amministratori, componenti inattesi, file modificati e altri indicatori coerenti con il proprio ambiente.

Quanto rapidamente bisogna intervenire su una falla critica?

Non esiste una finestra identica per ogni vulnerabilità. In questo caso, però, l’analisi pubblicata da Patchstack riferisce tentativi osservati circa 90 minuti dopo la pubblicazione della patch. È una dimostrazione concreta del perché le correzioni critiche vadano valutate e gestite immediatamente.

Perché l’assistenza annuale WordPress conta davvero

Una vulnerabilità come wp2shell chiarisce il valore di un’assistenza continuativa meglio di qualsiasi promessa commerciale. Quando viene pubblicata una falla critica, non basta sapere che esiste: bisogna capire quali siti sono coinvolti, intervenire rapidamente, verificare che l’aggiornamento sia riuscito e controllare che non siano rimasti segnali di compromissione. Chi ha affidato il proprio sito all’assistenza annuale BTSTUDIO non deve inseguire bollettini di sicurezza, interpretare sigle tecniche o eseguire aggiornamenti delicati in autonomia. Sui siti compresi nel servizio abbiamo verificato le versioni installate, applicato gli aggiornamenti necessari e controllato l’esito dell’intervento. È un lavoro che spesso il cliente non vede, perché avviene prima che il problema entri nella sua giornata. Ed è esattamente questo il senso dell’assistenza: poter continuare a lavorare sapendo che il sito viene seguito, aggiornato e controllato da chi lo conosce.