Richiedi assistenza

WordPress 7.1.4: cosa corregge l’aggiornamento di sicurezza e cosa verificare dopo l’upgrade

Staff

Il 28 ottobre 2026 è stato rilasciato WordPress 7.1.4, un aggiornamento di sicurezza che corregge diverse vulnerabilità nel core.

WordPress raccomanda esplicitamente di aggiornare i siti immediatamente.

Non si tratta quindi di una normale release di manutenzione.

Tra i problemi risolti troviamo una vulnerabilità nel processo di aggiornamento che, in determinate condizioni, può portare all’esecuzione remota di codice durante la finestra di upgrade, oltre a numerosi problemi di tipo Stored Cross-Site Scripting, information disclosure e denial of service.

Vediamo cosa è stato corretto e, soprattutto, cosa conviene controllare prima e dopo l’aggiornamento.

Cosa corregge WordPress 7.1.4

L’elenco ufficiale comprende diversi problemi di sicurezza.

Tra i più rilevanti troviamo:

  • una debolezza nel processo di aggiornamento di WordPress che può portare a Remote Code Execution durante la finestra di upgrade;
  • Stored XSS attraverso markup dei blocchi opportunamente costruito;
  • Stored XSS nelle richieste di cancellazione dei dati personali;
  • diversi Stored XSS nella Interactivity API;
  • un problema di Stored Denial of Service nella Interactivity API;
  • Stored XSS nel selective refresh del Customizer;
  • Stored XSS nel blocco Categorie;
  • Stored XSS ottenibile tramite username opportunamente costruiti;
  • esposizione a utenti non autenticati di changeset del Customizer non pubblicati;
  • Stored XSS nei blocchi Playlist e Immagine;
  • Stored XSS nei blocchi di navigazione precedente e successiva dei commenti;
  • accesso a note da parte di utenti privilegiati che non dispongono necessariamente dei permessi per modificare il contenuto associato.

La release aggiorna inoltre i certificati root inclusi in WordPress in seguito alla revoca di eMudhra.

Non tutti questi problemi hanno lo stesso impatto e alcuni richiedono determinati livelli di privilegio.

Il punto importante, però, è un altro: WordPress 7.1.4 è una security release e non andrebbe trattata come un aggiornamento facoltativo.

La vulnerabilità più delicata: il processo di aggiornamento

Tra le correzioni indicate dal Security Team, una merita particolare attenzione.

La release corregge una debolezza nel processo di upgrade che può consentire Remote Code Execution durante la finestra in cui WordPress viene aggiornato.

Questo non significa che ogni sito WordPress precedente alla 7.1.4 possa essere compromesso automaticamente.

Significa però che esisteva un percorso di attacco legato a una fase estremamente delicata: quella in cui il core viene sostituito con una nuova versione.

È anche un buon esempio del motivo per cui un processo di aggiornamento dovrebbe essere considerato parte della sicurezza del sito e non soltanto della manutenzione.

Stored XSS: perché ricorrono così spesso nella lista

Molte delle vulnerabilità corrette sono di tipo Stored Cross-Site Scripting.

In un attacco Stored XSS, codice JavaScript malevolo viene memorizzato nel sistema e successivamente eseguito nel browser di un altro utente quando quel contenuto viene visualizzato.

In WordPress l’impatto dipende fortemente da:

  • punto di ingresso;
  • capacità richiesta all’attaccante;
  • ruolo della vittima;
  • contesto in cui viene eseguito il codice.

Un XSS che richiede privilegi elevati ha una superficie d’attacco molto diversa da uno sfruttabile da un visitatore non autenticato.

Per questo motivo leggere semplicemente “XSS” non è sufficiente per valutare il rischio.

La release 7.1.4 corregge comunque numerosi vettori in aree differenti del core, dai blocchi alla Interactivity API fino al Customizer.

Devo aggiornare anche se uso gli aggiornamenti automatici?

Sì: devi almeno verificare che l’aggiornamento sia effettivamente avvenuto.

WordPress indica che i siti configurati per supportare gli aggiornamenti automatici in background iniziano automaticamente il processo di aggiornamento.

Questo, però, non significa che sia corretto presumere che ogni sito sia già protetto.

Gli aggiornamenti automatici possono non completarsi per diversi motivi:

  • permessi sui file;
  • timeout;
  • spazio disco insufficiente;
  • configurazioni particolari dell’hosting;
  • sistemi di deployment personalizzati;
  • installazioni gestite tramite Composer o Git;
  • modifiche ai file del core;
  • errori durante il processo di aggiornamento.

Conviene quindi controllare direttamente.

Vai in:

Bacheca → Aggiornamenti

e verifica la versione attualmente installata.

Se utilizzo una versione precedente a WordPress 7.1?

Il Security Team ha previsto backport delle correzioni anche per i rami più vecchi che ricevono ancora security fixes, fino alla serie 4.7.

Ad esempio, il 28 ottobre sono state pubblicate anche versioni aggiornate dei rami:

WordPress 7.0.8
WordPress 6.9.11
WordPress 6.7.11
WordPress 6.3.14
WordPress 6.1.16
WordPress 5.7.21
WordPress 5.2.30
WordPress 4.9.35
WordPress 4.8.34
WordPress 4.7.39

e altri aggiornamenti intermedi.

Questo non significa però che restare indefinitamente su una vecchia major release sia una buona strategia.

WordPress specifica che solo la versione più recente è attivamente supportata, mentre i backport di sicurezza per i vecchi rami sono forniti come misura aggiuntiva.

Per un sito mantenuto regolarmente, l’obiettivo dovrebbe quindi essere utilizzare l’ultima release stabile compatibile con l’ambiente.

Prima di aggiornare: fai un backup

Una security release va installata rapidamente, ma rapidità non significa improvvisazione.

Prima dell’aggiornamento verifica di avere almeno:

  • backup recente del database;
  • backup dei file;
  • copia di wp-content;
  • accesso al pannello dell’hosting;
  • credenziali SFTP o SSH, se disponibili.

Se utilizzi WooCommerce, assicurati in particolare che il backup del database sia realmente recente.

Ordini, clienti e dati delle transazioni possono cambiare continuamente e un backup di diversi giorni prima potrebbe non essere sufficiente in caso di rollback.

Aggiornamento automatico o manuale?

Nella maggior parte delle installazioni standard puoi aggiornare direttamente da:

Bacheca → Aggiornamenti → Aggiorna ora

WordPress 7.1.4 può anche essere scaricato dall’archivio ufficiale delle release.

Su siti gestiti tramite deployment strutturati, Composer, Git o pipeline CI/CD conviene invece seguire il normale processo di rilascio.

L’importante è evitare di mischiare più strategie.

Se il core viene normalmente gestito tramite versionamento o deployment automatico, effettuare improvvisamente un aggiornamento manuale dal backend può creare divergenze tra produzione e repository.

Cosa verificare subito dopo l’aggiornamento

Un aggiornamento completato senza errori non conclude necessariamente il lavoro.

Dopo l’upgrade conviene effettuare alcuni controlli.

1. Verifica la versione

Controlla che WordPress riporti effettivamente:

7.1.4

o la corrispondente release corretta del tuo ramo.

2. Controlla frontend e backend

Apri alcune pagine significative del sito e verifica:

  • homepage;
  • pagine interne;
  • articoli;
  • ricerca;
  • login;
  • area amministrativa.

Non è necessario navigare ogni URL.

L’obiettivo è individuare rapidamente eventuali errori evidenti.

3. Controlla i log

Se hai accesso ai log PHP o del server, verifica la presenza di nuovi:

  • Fatal Error;
  • warning;
  • exception;
  • errori REST;
  • problemi legati ai plugin.

Un sito che “sembra funzionare” può comunque generare errori silenziosi.

Controlli aggiuntivi per WooCommerce

Su un sito WooCommerce effettuerei alcune verifiche in più.

Controlla almeno:

  • pagina Shop;
  • prodotto;
  • aggiunta al carrello;
  • carrello;
  • checkout;
  • area My Account;
  • creazione di un ordine di test;
  • gateway di pagamento;
  • email transazionali;
  • eventuali webhook.

L’aggiornamento riguarda il core WordPress, non WooCommerce, ma il checkout e le integrazioni dipendono comunque dall’ambiente WordPress nel quale vengono eseguiti.

Un ordine di test completo vale spesso più di decine di controlli superficiali.

Verifica plugin e tema

Dopo aver aggiornato WordPress controlla anche eventuali aggiornamenti disponibili per:

  • plugin;
  • tema;
  • WooCommerce;
  • gateway;
  • plugin di sicurezza;
  • sistemi di cache.

Non significa necessariamente che tutto vada aggiornato simultaneamente.

Su siti complessi può essere preferibile procedere per gruppi e verificare progressivamente.

La cosa importante è evitare di lasciare per mesi estensioni obsolete accanto a un core aggiornato.

Non dimenticare gli account amministrativi

Una security release è anche una buona occasione per effettuare un controllo rapido degli utenti privilegiati.

Verifica gli account con ruolo:

  • Amministratore;
  • Editor, quando particolarmente rilevante;
  • Shop Manager su WooCommerce.

Controlla soprattutto:

  • account che non riconosci;
  • utenti non più necessari;
  • amministratori creati temporaneamente;
  • indirizzi email modificati;
  • ruoli anomali.

Questo controllo non deriva da una compromissione specifica della 7.1.4.

È semplicemente una buona pratica dopo aver rilevato o corretto un problema di sicurezza.

Devo cercare indicatori di compromissione?

La disponibilità di una patch non implica automaticamente che il sito sia stato attaccato.

Non è quindi corretto trattare ogni installazione precedente come compromessa.

Se però hai motivi concreti di sospettare un incidente, il semplice aggiornamento non basta.

In quel caso conviene verificare:

  • utenti amministratori;
  • file modificati recentemente;
  • plugin sconosciuti;
  • mu-plugin;
  • cron anomali;
  • access log;
  • error log;
  • richieste sospette;
  • modifiche ai file del core;
  • file PHP all’interno della directory uploads.

L’obiettivo è distinguere due operazioni differenti:

patching e incident response.

Aggiornare corregge la vulnerabilità.

Non elimina automaticamente eventuali modifiche effettuate da un attaccante prima dell’aggiornamento.

Posso rimandare perché il sito funziona?

Il fatto che il sito funzioni normalmente non dice nulla sulla presenza o meno della vulnerabilità.

Una patch di sicurezza non serve a correggere necessariamente un errore visibile.

Serve a eliminare un comportamento che potrebbe essere sfruttato.

Per questo la frase:

“Non aggiorno perché al momento funziona tutto”

non è una strategia efficace quando viene pubblicata una security release.

Aggiornare subito non significa aggiornare alla cieca

Esiste un equilibrio tra due esigenze:

  • ridurre il tempo di esposizione;
  • evitare regressioni su siti critici.

Per un blog o un sito istituzionale relativamente semplice, l’aggiornamento può spesso essere applicato rapidamente dopo backup e controlli essenziali.

Per un WooCommerce con numerose integrazioni, invece, può essere opportuno:

  1. creare o aggiornare lo staging;
  2. installare la security release;
  3. eseguire i test principali;
  4. controllare i log;
  5. aggiornare produzione;
  6. ripetere i controlli essenziali.

Il punto è evitare che “dobbiamo testare” diventi una giustificazione per rimandare indefinitamente un aggiornamento di sicurezza.

WordPress 7.1.4 e la frequenza recente delle security release

La 7.1.4 non arriva isolatamente.

Il team Security di WordPress segnala che nell’arco di 41 giorni sono state pubblicate quattro security release della serie 7.1: 7.1.1, 7.1.2, 7.1.3 e 7.1.4.

Questo non significa necessariamente che WordPress sia diventato improvvisamente meno sicuro.

Indica anche un’attività intensa di individuazione, disclosure responsabile e correzione dei problemi.

Dal punto di vista di chi gestisce un sito, però, il risultato pratico non cambia:

il processo di aggiornamento deve essere affidabile e monitorato.

Affidarsi a controlli manuali effettuati ogni diversi mesi non è più sufficiente per siti importanti.

Cosa fare adesso

Se gestisci un sito WordPress:

  1. verifica la versione installata;
  2. crea o controlla il backup più recente;
  3. aggiorna a WordPress 7.1.4 o alla security release corrispondente al tuo ramo;
  4. controlla frontend e backend;
  5. verifica i log;
  6. se utilizzi WooCommerce, effettua almeno un test completo del checkout;
  7. controlla gli utenti privilegiati;
  8. verifica che il sistema di aggiornamento automatico o il tuo processo di deployment funzioni realmente.

La parte più importante non è soltanto installare la 7.1.4.

È fare in modo che la prossima security release possa essere applicata rapidamente, verificata e tracciata senza dover improvvisare ogni volta.

Questo è il tipo di manutenzione che trasforma gli aggiornamenti WordPress da attività occasionale a vero processo di sicurezza.

Riferimenti ufficiali

Se devi aggiornare un sito WordPress o WooCommerce complesso e vuoi evitare che una security release introduca problemi in produzione, WPClinic può verificare l’ambiente, eseguire i controlli di compatibilità e assisterti nell’aggiornamento e nelle verifiche successive.