TL;DR: WordPress 7.0.2 corregge due vulnerabilità del Core, una delle quali può portare a esecuzione di codice quando viene combinata con una SQL injection. Se gestisci un sito aziendale, la risposta corretta non è cliccare “Aggiorna” alla cieca né rimandare: prepara un rollback verificato, applica la versione corretta per il tuo ramo, controlla checksum e funzioni critiche, poi osserva log e account amministrativi.

Il 17 luglio 2026 il team WordPress ha pubblicato la versione 7.0.2 e ha raccomandato l’aggiornamento immediato. La release interviene su una SQL injection facilitata in WP_Query e su una confusione delle route batch della REST API. Nelle versioni 6.9 e 7.0, la combinazione dei due problemi può portare a Remote Code Execution. Non è una correzione cosmetica.

Per una PMI il rischio più comune, però, nasce dalla gestione dell’emergenza: backup mai provati, aggiornamenti fatti direttamente in produzione, cache che nasconde il risultato e nessun controllo dopo il clic. Questa guida traduce l’avviso di sicurezza in una procedura eseguibile, sia da dashboard sia con WP-CLI.

Prima decisione: capire se il sito è nel ramo vulnerabile

Le versioni coinvolte non sono tutte uguali. Secondo gli advisory ufficiali, la SQL injection interessa WordPress dalla 6.8.0 alla 6.8.5, dalla 6.9.0 alla 6.9.4 e dalla 7.0.0 alla 7.0.1. La debolezza della REST API che completa la catena verso l’esecuzione di codice riguarda invece i rami 6.9 e 7.0.

Le versioni corrette sono:

  • 6.8.6 per chi deve restare temporaneamente sul ramo 6.8;
  • 6.9.5 per il ramo 6.9;
  • 7.0.2 per il ramo 7.0.

Le versioni precedenti alla 6.8 non risultano coinvolte da queste due vulnerabilità, ma questo non le rende una scelta prudente: WordPress ricorda che solo la versione più recente è attivamente supportata. Restare molto indietro per evitare un aggiornamento urgente significa scambiare un rischio noto con un debito di sicurezza più ampio.

Dalla dashboard trovi la versione in Bacheca → Aggiornamenti. Con accesso shell puoi verificarla senza caricare pagine del front-end:

wp core version
wp core check-update

Se leggi 6.8.5, 6.9.4, 7.0.1 o una versione precedente dello stesso ramo vulnerabile, il sito va aggiornato. Se leggi già 6.8.6, 6.9.5 o 7.0.2, non fermarti al numero: passa ai controlli di integrità e ai log.

Il backup serve solo se sai ripristinarlo

La documentazione WordPress raccomanda un backup prima dell’aggiornamento. La parola importante non è “backup”, ma “ripristino”. Un archivio nel pannello hosting non è ancora un piano di rollback.

Prima di toccare il Core, verifica quattro elementi:

  • dump recente e leggibile del database;
  • copia dei file, soprattutto wp-content e wp-config.php;
  • accesso indipendente a hosting, SFTP o SSH, utile se wp-admin smette di rispondere;
  • procedura e tempo stimato per rimettere online l’ultima copia buona.

Su un e-commerce, un portale soci o un sito con moduli che scrivono dati, annota anche il momento esatto del backup. Ripristinare il database di due ore prima può risolvere il guasto tecnico e cancellare ordini, richieste o registrazioni arrivate nel frattempo.

La mia posizione è netta: per una patch critica non serve una settimana di staging, ma serve un rollback credibile. Una copia automatica mai ripristinata non giustifica il rinvio. Prepara l’uscita di sicurezza, fai un test rapido sulle funzioni ad alto valore e riduci il tempo di esposizione.

Aggiornare senza trasformare la patch in un fermo sito

Se hai uno staging aggiornato e rappresentativo, usalo per un passaggio veloce: login, modifica di una pagina, invio controllato di un modulo, acquisto di prova se esiste WooCommerce e chiamate REST usate da integrazioni esterne. Lo staging non deve diventare una scusa per lasciare la produzione vulnerabile.

Prima dell’update registra lo stato corrente:

wp core version
wp plugin list --status=active
wp theme list --status=active

Poi aggiorna il Core. Da wp-admin usa Bacheca → Aggiornamenti. Da WP-CLI:

wp core update
wp core update-db

wp core update-db esegue l’eventuale procedura di aggiornamento del database richiesta dal nuovo codice. Non sostituisce il backup e non va usato per “riparare” un database già danneggiato.

Evita di accorpare nello stesso minuto Core, tutti i plugin, tema, versione PHP e configurazione cache. Se qualcosa si rompe, non saprai quale modifica ha causato il problema. In questa emergenza il Core viene prima, perché le vulnerabilità corrette sono nel Core. Gli altri aggiornamenti restano importanti, ma vanno gestiti come cambi separati e osservabili.

Se usi un servizio gestito, controlla che l’aggiornamento automatico sia realmente avvenuto. WordPress ha abilitato aggiornamenti forzati per i siti interessati, ma un’installazione può non riceverli per permessi dei file, configurazioni che disattivano l’updater, problemi di WP-Cron o policy dell’hosting. “Dovrebbe essersi aggiornato” non è una verifica.

Checksum: il controllo che manca dopo il clic

Dopo l’aggiornamento esegui il controllo dei file del Core:

wp core verify-checksums --include-root --version=$(wp core version)

Il comando confronta i file installati con i checksum pubblicati da WordPress.org e viene eseguito prima del caricamento di WordPress. Questo dettaglio è utile: un plugin o un tema difettoso non deve avviarsi per permettere la verifica.

Un risultato positivo conferma che i file noti del Core coincidono con quelli della release. Non certifica che l’intero sito sia pulito. wp-content, plugin premium, mu-plugin e file aggiunti da un attaccante richiedono controlli separati. La guida ufficiale WP-CLI segnala anche che file inattesi in wp-admin, wp-includes o nella root possono comparire come warning quando usi --include-root.

Se il checksum fallisce, non copiare semplicemente il file segnalato sopra quello esistente e non cancellare le prove. Salva output, timestamp e copia dei file sospetti, poi confronta con una sorgente pulita. Su un sito che tratta dati personali o transazioni, coinvolgi chi gestisce sicurezza e hosting prima di ripristinare.

Smoke test: controllare ciò che produce valore

Il test post-update deve essere corto e specifico. Aprire la homepage non basta. Controlla almeno:

  • homepage e una pagina interna in finestra anonima;
  • login e caricamento di wp-admin;
  • salvataggio di una bozza, senza pubblicarla;
  • modulo o checkout in modalità di test, usando destinatari e pagamenti autorizzati;
  • endpoint REST usati da app, CRM, Make, n8n o integrazioni personalizzate;
  • job pianificati e Site Health, soprattutto se gli aggiornamenti automatici dipendono da WP-Cron;
  • assenza di errori PHP fatali e picchi di risposte 5xx nei log.

Se il sito usa una cache server, un CDN o un plugin di page cache, purgala dopo l’aggiornamento. La stessa documentazione WordPress lo indica tra i passaggi finali: senza purge potresti vedere una copia vecchia e dichiarare riuscita una verifica che non ha ancora toccato il codice nuovo.

Per i flussi editoriali vale lo stesso principio descritto nella mia guida sulle bozze AI in WordPress: la pubblicazione non è un singolo clic, ma una sequenza di gate. Qui i gate sono versione, checksum, funzioni critiche, log e rollback.

Controllare se il problema è iniziato prima della patch

Aggiornare chiude la vulnerabilità nota, ma non dimostra che il sito non sia stato toccato. Se l’installazione è rimasta su una versione vulnerabile, esegui una triage proporzionata al valore del sito.

Controlla gli utenti amministratori creati o modificati di recente, le chiavi e le Application Password attive, i file PHP nuovi o cambiati, i cron inattesi, le regole di redirect, i log della REST API e le connessioni in uscita insolite. Cerca indicatori concreti, non la semplice presenza di traffico verso wp-json: la REST API è una parte normale di WordPress.

Se trovi segnali credibili di compromissione, la procedura cambia. Conserva le evidenze, isola il sito quando necessario, ricostruisci da una base pulita, ruota credenziali e chiavi, poi verifica database e integrazioni. Ripristinare solo i file del Core può lasciare intatti un account amministratore abusivo, un mu-plugin o una modifica nel database.

Questo è anche il motivo per cui sconsiglio i plugin di sicurezza usati come alibi operativo. Possono aggiungere telemetria e blocchi utili, ma non sostituiscono inventario, aggiornamenti, backup ripristinabili e logging. La sicurezza WordPress è un processo di manutenzione, non una schermata con un punteggio verde.

Una procedura minima per PMI e professionisti

Per un singolo sito vetrina la procedura può stare in trenta minuti. Per dieci siti clienti va automatizzata, ma senza togliere i controlli.

  1. Inventaria versione WordPress, hosting, responsabile e canale di accesso di emergenza.
  2. Conferma un backup recente di database e file e annota come ripristinarlo.
  3. Verifica il ramo installato e applica 6.8.6, 6.9.5 o 7.0.2 secondo il caso.
  4. Esegui checksum del Core con --include-root.
  5. Prova le funzioni che generano contatti, ordini, prenotazioni o pubblicazioni.
  6. Purga le cache e ricontrolla come utente anonimo.
  7. Osserva log, utenti amministrativi e task pianificati nelle ore successive.
  8. Registra esito, orario, versione finale e anomalie. Se il sito è cliente, comunica cosa è stato verificato, non solo che “l’update è fatto”.

Su più installazioni, fai produrre allo script un report macchina e un riepilogo umano. La lezione vale anche per le automazioni AI: l’output utile non è il comando eseguito, ma la prova che lo stato finale rispetta i criteri. Ne ho parlato anche nella guida su come validare l’output AI prima di WordPress.

Take-away

WordPress 7.0.2 non richiede panico. Richiede disciplina. Aggiornare in fretta è corretto perché la catena documentata arriva alla Remote Code Execution sui rami 6.9 e 7.0. Farlo senza backup verificato, checksum e smoke test significa affidare la continuità del sito alla fortuna.

La checklist minima è semplice: versione corretta, rollback disponibile, Core integro, funzioni critiche operative, cache svuotata e log osservati. Se uno di questi punti manca, l’aggiornamento non è concluso.

Fonti