Sicurezza WordPress dopo l’update 7.0.3: checklist e controlli da eseguire

WordPress 7.0.3 è un aggiornamento di sicurezza pubblicato il 6 agosto 2026 per correggere 12 vulnerabilità nel core. La più rilevante è una reflected XSS pre-autenticazione nella schermata di login, classificata High nell’advisory ufficiale GitHub.

Installare la versione corretta è indispensabile, ma non basta per chiudere professionalmente l’intervento. Dopo l’aggiornamento bisogna confermare la versione effettivamente installata, controllare l’integrità del sito, esaminare accessi e componenti e verificare le funzioni critiche.

La distinzione fondamentale è questa: la patch chiude le vulnerabilità corrette, ma non dimostra che il sito fosse integro prima dell’installazione e non rimuove automaticamente eventuali modifiche malevole già presenti.

WordPress 7.0.3: cosa corregge l’aggiornamento di sicurezza

La release 7.0.3 interviene su 12 vulnerabilità del core. Il problema maggiormente evidenziato riguarda una reflected XSS pre-auth nella pagina di login, presente nelle versioni di WordPress dalla 4.7 alla 7.0.2.

Per le installazioni appartenenti al ramo 7.0, la versione corretta è WordPress 7.0.3. Le correzioni sono state retroportate anche su rami precedenti, fino alla versione 4.7.34.

Tra gli altri problemi risolti figurano:

• quattro stored XSS accessibili almeno a utenti con ruolo Contributor;
• una CSS injection;
• una SSRF verso indirizzi link-local;
• una privilege escalation in ambiente Multisite;
• problemi di esposizione o enumerazione di informazioni.

Condizioni di sfruttamento e impatto possono variare. Non è quindi corretto attribuire automaticamente alle altre vulnerabilità la stessa gravità della XSS evidenziata nell’advisory.

Perché la XSS del login è rilevante, senza definirla una RCE automatica

La vulnerabilità interessa la schermata di login ed è sfruttabile prima dell’autenticazione. Questo elemento ne aumenta la rilevanza, ma non significa che un sito vulnerabile venga compromesso automaticamente.

La possibile escalation fino all’esecuzione di codice PHP richiede social engineering, un’interazione esplicita da parte della vittima e condizioni ulteriori. Non si tratta quindi di una RCE automatica o senza interazione, né la disponibilità online di una versione vulnerabile dimostra che il sito sia già stato violato.

La risposta corretta consiste nell’aggiornare e svolgere verifiche proporzionate all’esposizione e alla criticità del progetto, evitando sia minimizzazioni sia conclusioni allarmistiche non supportate.

Primo controllo: confermare la versione realmente installata

Una notifica di aggiornamento non è sufficiente per confermare che l’operazione sia andata a buon fine. La versione deve essere verificata direttamente nell’installazione.

È possibile controllarla dalla Bacheca di WordPress oppure, se WP-CLI è disponibile, con:

wp core version

Per un sito appartenente al ramo 7.0, il valore atteso dopo l’aggiornamento è 7.0.3. È inoltre possibile verificare la disponibilità di ulteriori aggiornamenti con:

wp core check-update

Quando disponibili, è utile consultare anche le e-mail generate dagli aggiornamenti automatici e i log messi a disposizione dal provider. Nel ticket o nel rapporto di manutenzione devono essere annotate almeno la versione iniziale e quella finale.

Backport e vecchie major: perché non sono una strategia di lungo periodo

Le correzioni distribuite sui rami precedenti consentono di mitigare le vulnerabilità anche quando non è possibile completare subito un passaggio di major. Tuttavia, un backport non deve essere interpretato come una garanzia di supporto permanente.

WordPress indica come ufficialmente supportata in modo continuativo soltanto l’ultima major release. Le correzioni per i rami precedenti possono essere distribuite, ma senza garanzia di continuità.

Per un progetto gestito professionalmente, la presenza di un backport dovrebbe quindi essere considerata una misura utile nell’immediato, non una strategia per rimanere indefinitamente su una major obsoleta. L’eventuale aggiornamento di major richiede comunque pianificazione, backup e test di compatibilità.

Patch applicata non significa sito certamente integro

L’aggiornamento impedisce di continuare a esporre le vulnerabilità corrette, ma non ricostruisce ciò che potrebbe essere successo prima della patch. In particolare, non elimina automaticamente:

• file PHP aggiunti o modificati;
• account o ruoli creati senza autorizzazione;
• redirect e JavaScript estranei;
• plugin, temi o mu-plugin installati abusivamente;
• modifiche a configurazioni, cron job o database.

Allo stesso tempo, avere utilizzato una versione vulnerabile non prova che il sito sia stato compromesso. La formulazione corretta, dopo controlli ordinari senza anomalie, è “nessun indicatore rilevato”. Non equivale alla certezza forense di assenza di compromissione.

Checklist di integrità: core, file e configurazioni

1. Verificare i file del core

Con WP-CLI è possibile confrontare i file del core con le checksum ufficiali:

wp core verify-checksums

Questo comando è utile per rilevare differenze nei file core, ma non controlla plugin, temi, cartella degli upload o database. Un risultato regolare non certifica quindi l’integrità dell’intera installazione.

2. Cercare modifiche inattese

Il controllo deve includere file PHP nuovi o modificati e le aree sensibili dell’installazione:

• wp-config.php;
• .htaccess;
• mu-plugin;
• cron job;
• plugin e temi attivi o disattivati;
• redirect e script JavaScript non riconosciuti.

Le modifiche devono essere confrontate con gli interventi previsti, la cronologia del progetto e i componenti autorizzati.

3. Controllare plugin e temi

La sicurezza WordPress non dipende esclusivamente dal core. Bisogna verificare versione e stato di manutenzione di plugin e temi, compresi quelli disattivati ma ancora presenti sul server. I componenti non necessari o non riconosciuti richiedono una valutazione specifica.

4. Verificare permessi e configurazione

La documentazione WordPress raccomanda permessi limitati e la disattivazione dell’editor integrato quando non è necessario. Il controllo deve inoltre considerare infrastruttura, configurazione del server e possibilità di ripristinare realmente i backup.

Log, utenti e ruoli: cosa controllare dopo l’update

Se il sito è rimasto esposto prima dell’applicazione della patch, è opportuno conservare i log prima che vengano eliminati dalla normale rotazione. Le richieste verso wp-login.php meritano particolare attenzione, ma vanno analizzate nel contesto complessivo dell’attività del sito.

La verifica degli account dovrebbe comprendere:

• amministratori presenti e autorizzati;
• ruoli modificati di recente;
• accessi insoliti;
• utenti inattivi ancora abilitati;
• account Contributor, Author, Editor e Administrator;
• plugin o temi installati senza un intervento pianificato.

Nei siti gestiti da redazioni o collaboratori conviene controllare anche revisioni, modifiche ai contenuti e attività Quick Edit. L’obiettivo è individuare operazioni che non siano riconducibili alle normali attività editoriali.

Quando passare dai controlli ordinari all’incident response

Il cambio indiscriminato di password, secret key e salt non è un requisito automatico per ogni aggiornamento. Queste misure diventano appropriate quando emergono indicatori sospetti o esiste una possibile esposizione di credenziali e sessioni.

In tale situazione può essere necessario:

1. forzare il logout delle sessioni attive;
2. rigenerare secret key e salt;
3. cambiare le credenziali potenzialmente esposte;
4. ruotare token e API key coinvolti;
5. attivare la 2FA sugli account privilegiati;
6. preservare log ed elementi utili alle verifiche successive.

Queste attività fanno parte della risposta a un possibile incidente. La loro esecuzione non dimostra, da sola, che la compromissione sia avvenuta.

Smoke test: verificare che il sito funzioni dopo l’aggiornamento

Un ticket di aggiornamento non dovrebbe essere chiuso senza aver controllato le funzioni importanti per utenti, redazione e attività del cliente.

La checklist minima può includere:

• login e recupero password;
• editor, Quick Edit e pubblicazione dei contenuti;
• form di contatto e altri moduli;
• checkout, se presente;
• aree riservate;
• landing page principali;
• REST API;
• integrazioni esterne;
• tracking e strumenti collegati.

Dopo l’update può essere necessario svuotare cache applicativa, object cache, CDN e cache del browser. Se il progetto utilizza sistemi di aggregazione JavaScript, gli asset devono essere rigenerati prima dei test conclusivi.

La profondità delle verifiche deve essere adeguata al progetto:

• Sito vetrina: pagine principali, moduli, login amministrativo, tracking e cache.
• Sito con redazione: flussi editoriali, ruoli, revisioni, Quick Edit e pubblicazione.
• Multisite: amministrazione della rete, ruoli, siti collegati e funzioni condivise.

Come documentare correttamente l’intervento

La sola dicitura “aggiornamento eseguito” non permette al cliente o all’agenzia di capire che cosa sia stato realmente verificato.

Un rapporto di chiusura dovrebbe indicare:

• versione WordPress iniziale e finale;
• disponibilità e stato del backup;
• controlli di integrità effettuati;
• log e utenti esaminati;
• test funzionali completati;
• eventuali indicatori sospetti;
• azioni correttive intraprese;
• componenti obsoleti, disattivati o non mantenuti da gestire successivamente.

Se non sono emerse anomalie, è corretto riportare “nessun indicatore rilevato nei controlli eseguiti”. Non bisogna trasformare questa conclusione nella garanzia assoluta che il sito non sia mai stato compromesso: un controllo tecnico ordinario non equivale a un’analisi forense completa.

Checklist rapida post-aggiornamento

1. Verificare che sul ramo 7.0 sia installato WordPress 7.0.3.
2. Registrare versione iniziale e versione finale.
3. Controllare disponibilità e ripristinabilità del backup.
4. Eseguire il controllo delle checksum del core.
5. Esaminare file, configurazioni, mu-plugin e cron job.
6. Controllare plugin e temi, inclusi quelli disattivati.
7. Conservare e analizzare i log pertinenti.
8. Verificare amministratori, utenti inattivi e ruoli modificati.
9. Cercare redirect, JavaScript o componenti non autorizzati.
10. Eseguire i test delle funzioni critiche.
11. Svuotare le cache e rigenerare gli asset quando necessario.
12. Documentare controlli, risultati e attività da pianificare.

Domande frequenti sulla sicurezza WordPress 7.0.3

Quali versioni sono interessate dalla XSS nella schermata di login?

La vulnerabilità riguarda le versioni di WordPress dalla 4.7 alla 7.0.2. Per il ramo 7.0, la versione corretta è WordPress 7.0.3. Sono disponibili backport anche per rami precedenti, fino alla versione 4.7.34.

WordPress 7.0.3 elimina eventuali compromissioni precedenti?

No. L’aggiornamento corregge le vulnerabilità interessate, ma non rimuove automaticamente file, utenti, redirect o altre modifiche malevole eventualmente introdotte prima della patch.

Come posso verificare che WordPress 7.0.3 sia installato?

È possibile controllare la versione dalla Bacheca di WordPress o tramite il comando wp core version. Per un’installazione sul ramo 7.0, il risultato atteso è 7.0.3.

Che cosa controlla wp core verify-checksums?

Confronta i file del core WordPress con le checksum ufficiali. Non verifica plugin, temi, upload o database e non rappresenta un controllo completo dell’intero sito.

I backport permettono di restare senza rischi su una vecchia major?

No. I backport forniscono correzioni anche su alcuni rami precedenti, ma senza garanzia di continuità. Solo l’ultima major è indicata come ufficialmente supportata in modo continuativo.

È necessario cambiare password, salt e secret key dopo ogni aggiornamento?

Non automaticamente. La rotazione è una misura di incident response appropriata quando emergono anomalie o una possibile esposizione, non un obbligo indistinto per ogni aggiornamento.

Quali test bisogna eseguire dopo un aggiornamento di sicurezza?

Vanno testati almeno login, recupero password, pubblicazione, form e funzioni critiche del progetto. In base al sito possono essere inclusi checkout, aree riservate, REST API, integrazioni, tracking, cache e flussi editoriali.

L’assenza di anomalie dimostra che il sito non è stato compromesso?

No. Permette di dichiarare che non sono stati rilevati indicatori durante i controlli effettuati, ma non offre una certezza forense assoluta.

Serve supporto per la verifica post-patch?

Posso supportare agenzie, professionisti e responsabili di siti nell’aggiornamento, nella verifica tecnica post-patch, nei test delle funzioni critiche e nella documentazione dell’intervento. Contattami per saperne di più.