WordPress 7.0.2: cosa è successo e perché devi aggiornare subito
Il 17 luglio 2026 WordPress ha rilasciato la versione 7.0.2, un aggiornamento di sicurezza che corregge due vulnerabilità: una critica e una di gravità alta. Non è il solito aggiornamento di manutenzione: la falla critica permette a un attaccante senza alcuna credenziale di eseguire codice sul server di un sito WordPress con installazione standard.
Se gestisci un sito WordPress, questa è una di quelle notizie da leggere adesso e non lunedì.
Cosa è successo
L’aggiornamento risolve due problemi segnalati responsabilmente attraverso il programma HackerOne di WordPress:
- CVE-2026-63030, soprannominata wp2shell: una confusione nella gestione delle rotte dell’endpoint batch delle REST API che, concatenata all’altra falla, porta all’esecuzione di codice da remoto (RCE). È la vulnerabilità critica, individuata da Adam Kues del team Assetnote di Searchlight Cyber.
- CVE-2026-60137: una SQL injection, segnalata dal team composto da TF1T, dtro e haongo. È il secondo anello della catena.
Il punto che rende questa vicenda diversa dal solito è la facilità di sfruttamento. Secondo i ricercatori l’attacco non richiede precondizioni: nessun login, nessun plugin di terze parti, nessuna configurazione particolare. Una installazione WordPress standard è attaccabile con una semplice richiesta HTTP anonima. E l’endpoint batch delle REST API fa parte del core, è attivo per impostazione predefinita e raggiungibile senza autenticazione: non è quindi un caso limite di configurazione.
L’esecuzione di codice da remoto è la classe di vulnerabilità più grave che esista. Uno sfruttamento riuscito significa, in pratica, che l’attaccante ottiene il controllo del sito.
Cosa può fare un attaccante, e con quali conseguenze
“Prende il controllo del sito” suona astratto. In concreto, potendo eseguire codice sul server, un attaccante può:
- Creare utenti amministratori nascosti e mantenere l’accesso anche dopo un aggiornamento.
- Installare backdoor persistenti che sopravvivono alle pulizie superficiali.
- Rubare i dati del database: anagrafiche clienti, ordini, indirizzi email, password (che, anche se cifrate, diventano attaccabili con calma offline).
- Iniettare redirect verso siti di malware o truffe, o inserire spam e link nascosti che distruggono il posizionamento su Google.
- Deturpare le pagine (defacement) o mandare il sito offline.
- Usare il tuo server per attaccare altri siti o inviare spam, con il tuo dominio che finisce nelle blocklist.
- Accedere ad altri siti ospitati sullo stesso hosting, se l’ambiente non è isolato.
- Cifrare o sequestrare il sito e chiedere un riscatto.
Un rischio spesso sottovalutato riguarda le chiavi API. Se sul sito o sul server sono configurate chiavi di servizi a consumo, ad esempio modelli di intelligenza artificiale, invio di email o SMS, servizi cloud, chi ottiene l’accesso può rubarle e usarle a tuo nome. Il risultato può essere una bolletta molto salata, che matura in fretta e arriva magari prima ancora che tu ti accorga dell’intrusione.
E il conto vero arriva dopo l’attacco: giorni di lavoro per bonifica e ripristino, l’eventuale notifica al Garante se sono stati violati dati personali (GDPR), la perdita di fiducia dei clienti e il fatturato perso mentre il sito è fuori uso o compromesso.
Quali versioni sono a rischio
Qui molti articoli generano confusione, quindi vale la pena essere precisi. Non tutte le versioni di WordPress sono vulnerabili alla catena RCE.
| Versione | Situazione | Versione corretta |
|---|---|---|
| 7.0.0 – 7.0.1 | Vulnerabile a entrambe le falle | 7.0.2 |
| 6.9.0 – 6.9.4 | Vulnerabile a entrambe le falle | 6.9.5 |
| 6.8.x | Vulnerabile solo alla SQL injection | 6.8.6 |
| 7.1 beta | Vulnerabile a entrambe le falle | 7.1 beta2 |
| Precedenti alla 6.8 | Non interessate | — |
Il codice vulnerabile alla catena RCE esiste a partire dalla 6.9, rilasciata a dicembre 2025. Un sito su una versione più vecchia non è esposto a questa specifica vulnerabilità: il che non lo rende comunque sicuro, perché quelle versioni hanno altri problemi noti.
Perché la situazione è urgente
Data la gravità, il team di WordPress.org ha attivato gli aggiornamenti forzati tramite il sistema di auto-update per i siti che eseguono versioni interessate. È una misura eccezionale, adottata solo quando il rischio è concreto e diffuso.
Searchlight Cyber ha volutamente trattenuto i dettagli tecnici dell’exploit per dare tempo agli amministratori di aggiornare, pubblicando solo uno strumento di verifica pubblico. Ma nelle ore successive alla divulgazione sono già stati segnalati proof of concept in circolazione e le prime avvisaglie di sfruttamento reale. Detto in modo diretto: se un tuo sito gira su una versione interessata, il ragionamento corretto non è “quando trovo tempo lo aggiorno”, ma “considero quel sito esposto finché non è aggiornato”.
Come verificare la tua versione in 30 secondi
Entra in bacheca WordPress e guarda il riquadro “A colpo d’occhio”: la versione è indicata lì. In alternativa la trovi in Aggiornamenti o nel file readme.html alla radice dell’installazione. Se gestisci molti siti, esistono verificatori pubblici online e strumenti come WPScan per la scansione.
Cosa fare, subito
- Aggiorna il core. Dalla bacheca: Aggiornamenti → Aggiorna ora. Se il sito supporta gli aggiornamenti automatici, il processo potrebbe essere già partito da solo: verifica comunque che sia andato a buon fine, perché un aggiornamento forzato può fallire in silenzio su installazioni con permessi file particolari.
- Controlla di essere davvero sulla versione corretta (7.0.2, 6.9.5 o 6.8.6 a seconda del ramo).
- Ripeti su tutti i siti che gestisci, compresi staging e progetti dimenticati. Un sito abbandonato sullo stesso server è comunque una porta aperta.
Se non puoi aggiornare immediatamente
Capita: un sito con personalizzazioni pesanti dove l’aggiornamento va testato prima. In quel caso i ricercatori suggeriscono misure temporanee, come limitare l’accesso anonimo alle REST API o bloccare a livello di web application firewall le richieste verso l’endpoint batch. Due avvertenze: queste mitigazioni possono rompere integrazioni legittime che usano le REST API, quindi sono cerotti temporanei e non alternative all’aggiornamento; ed è circolata la voce che una cache a oggetti persistente (Redis, Memcached) metta al riparo, ma non è una protezione e non va intesa come tale.
Come capire se sei stato compromesso
Se un tuo sito è rimasto su una versione vulnerabile dopo la divulgazione, l’aggiornamento chiude la porta ma non rimuove un’eventuale intrusione già avvenuta. Vale la pena controllare utenti amministratori sconosciuti aggiunti di recente, file modificati in date sospette (soprattutto in wp-content e nella radice), i log di accesso verso gli endpoint REST e le attività pianificate che non riconosci. Se trovi qualcosa, la strada giusta non è cancellare il file e sperare: serve un ripristino da un backup precedente all’intrusione, seguito dall’aggiornamento e dal cambio di tutte le credenziali.
La lezione: perché la manutenzione non è un costo opzionale
Questa vicenda dimostra un principio che ripeto spesso ai clienti: la sicurezza di un sito WordPress non è uno stato, è un processo.
Nota una cosa: qui non c’entrano i plugin. Il consiglio classico “usa pochi plugin e tienili aggiornati” è sacrosanto, ma non avrebbe protetto nessuno. La falla era nel core, in codice attivo per impostazione predefinita su ogni installazione. L’unica difesa reale era applicare l’aggiornamento in fretta.
E qui si vede la differenza tra un sito seguito e uno lasciato a sé stesso. Non è una questione di competenza del proprietario: è che qualcuno deve accorgersi che è uscito un aggiornamento di sicurezza critico, verificare quali siti sono interessati, applicarlo e controllare che sia andato a buon fine. Un venerdì sera d’estate, mentre tu stai facendo altro.
Il paradosso della manutenzione fatta bene è che, quando funziona, sembra che non stia succedendo niente. Giornate come questa sono l’eccezione in cui si vede a cosa serve.
Domande frequenti
Domande frequenti
Il mio sito si aggiorna da solo, sono a posto?
Probabilmente sì, perché per questa release sono stati attivati gli aggiornamenti forzati. Ma gli aggiornamenti automatici possono fallire, ad esempio per permessi sui file. Vale sempre la pena verificare la versione manualmente in bacheca.
Uso WordPress 6.8, sono vulnerabile?
Alla catena RCE no: quel codice esiste dalla 6.9. Sei però interessato dalla SQL injection, corretta nella 6.8.6. Aggiorna comunque.
Basta disattivare i plugin per proteggersi?
No. La vulnerabilità è nel core di WordPress, non in un plugin. Disattivare i plugin non cambia nulla.
Se ho Redis o Memcached sono al sicuro?
No. Il percorso di sfruttamento divulgato riguarda i casi senza cache a oggetti persistente, ma non va inteso come una protezione. L'unico rimedio è l'aggiornamento.
Come faccio a sapere se il mio sito è stato attaccato?
Controlla nuovi utenti amministratori, file modificati di recente e i log di accesso verso gli endpoint REST. In caso di dubbio, fatti dare un'occhiata da qualcuno che sa dove guardare.