Release di sicurezza WordPress 7.1.4: cosa devono fare oggi le agenzie

Aggiornamento, 5 novembre 2026: Wordfence conta ora oltre 240.000 tentativi bloccati contro questa falla dal 28 ottobre, con un picco di oltre 74.000 il 30 ottobre. Il 2 novembre la CISA ha aggiunto CVE-2026-119977 al catalogo Known Exploited Vulnerabilities. Wordfence considera ancora difficile in pratica un attacco riuscito, perché funziona solo nei secondi in cui gira un aggiornamento. Il loro consiglio è lo stesso nostro: aggiorna ora alla 7.1.4 o al backport del tuo ramo, e blocca i file PHP in wp-content/upgrade/ a livello di web server prima di aggiornare. Gli utenti gratuiti di Wordfence ricevono la regola firewall il 27 novembre. Fonte: Wordfence, 5 novembre 2026.

Aggiornamento, 31 ottobre 2026: gli attacchi stanno aumentando. Wordfence segnala ora quasi 59.000 tentativi bloccati in 24 ore contro i file di installazione temporanei in wp-content/upgrade/ (contro 18.500 nelle prime 21 ore). Ancora nessuna intrusione confermata. Se un sito cliente non è ancora sulla 7.1.4 o sul backport del suo ramo, aggiornalo oggi e chiudi la cartella upgrade sul server; non aspettare lunedì.

WordPress 7.1.4 è uscito il 28 ottobre 2026 come release di sicurezza. Corregge 22 vulnerabilità in 17 avvisi, e le stesse correzioni sono state riportate su ogni ramo supportato fino alla 4.7.39. Una è insolita: una falla nel processo di aggiornamento del core stesso, senza bisogno di login. È difficile da sfruttare, ma gli attaccanti hanno iniziato a cercarla entro un giorno, ed è l’unico problema di questa release che un firewall sotto forma di plugin non può fermare. Ecco cosa significa per i siti clienti che gestisci e cosa fare oggi.

Cosa viene corretto

• Esecuzione di codice senza login durante un aggiornamento. Prima della 7.1.4, la cartella in cui WordPress estrae gli aggiornamenti, dentro wp-content/upgrade/, aveva un nome prevedibile, e la pulizia rimuoveva il index.php che blocca l’elenco del contenuto della cartella. Un attaccante che coglie i pochi secondi in cui gira un aggiornamento, su un sito dove quella cartella è raggiungibile dal web, poteva eseguire codice. Patchstack valuta alta la complessità dell’attacco e non considera pratico lo sfruttamento. Poiché la copia estratta non carica i plugin del tuo sito, un plugin firewall a livello PHP non può bloccare questa richiesta.
• XSS memorizzato a partire dagli account Collaboratore, soprattutto nella Interactivity API (7 dei 17 avvisi) e in diversi blocchi del core.
• Customizer: i set di modifiche non pubblicati potevano essere visti da visitatori non loggati.

Chi è coinvolto

Ogni sito con una versione inferiore alla 7.1.4 o al backport corrispondente (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 e così via, fino alla 4.7.39). I siti sulla 4.6 o precedente non ricevono alcuna correzione. I problemi XSS contano di più sui siti dove clienti, redattori o autori ospiti hanno account Collaboratore o superiori.

Controlla un sito in due minuti

1. Versione: in wp-admin vai su Bacheca → Aggiornamenti, oppure esegui wp core version. Tutto ciò che è sotto la 7.1.4 (o il backport del tuo ramo) ha bisogno dell’aggiornamento.
2. Cartella upgrade: apri https://example.com/wp-content/upgrade/ in una finestra privata. Un 403 o un 404 è ciò che vuoi. Un elenco di file o una pagina 200 vuota significa che la cartella è raggiungibile dal web.
3. Account: in Utenti filtra per Collaboratore, Autore ed Editore. Rimuovi quelli che nessuno usa.

Cosa fare ora

1. Aggiorna il core alla 7.1.4 o al backport del tuo ramo. Le release di sicurezza minori di solito si installano da sole; controlla che sia successo, perché hosting e alcuni plugin disattivano gli aggiornamenti automatici del core. Assicurati prima di avere un backup recente, e controlla dopo homepage, un modulo e il checkout.
2. Blocca l’accesso web alla cartella upgrade sul web server, non con un plugin. Su Apache, un file .htaccess in wp-content/upgrade/ con Require all denied. Su nginx, location ^~ /wp-content/upgrade/ { deny all; }. WordPress continua a scrivere nella cartella tramite PHP, quindi gli aggiornamenti funzionano ancora. Su un hosting gestito dove non puoi modificare il server, chiedilo al tuo hosting.
3. Siti sulla 4.6 o precedente: pianifica ora il passaggio a una versione supportata. Per loro non ci sarà una correzione.

Gli attaccanti cercano questa falla, ma non sono state confermate intrusioni riuscite, quindi un sito aggiornato con la cartella upgrade chiusa non ha bisogno di ripristino né di nuove chiavi solo per questa release. Se invece vedi file sconosciuti in wp-content/upgrade/ o nuovi account amministratore, trattalo come una compromissione: ripristina da un backup precedente alla comparsa di quei file, poi cambia password e salt. La nostra routine per il giorno di una vulnerabilità contiene tutti i passaggi.

Come aiuta Verploy

Ogni aggiornamento viene controllato. Quelli rischiosi vengono testati prima su una copia. Il core di WordPress conta sempre come rischioso: viene testato su una copia privata del sito prima che il sito online cambi e, se un controllo fallisce dopo la pubblicazione, il sito viene riportato indietro in automatico. I backup notturni cifrati nell’UE ti danno un punto pulito a cui tornare, e le vulnerabilità note compaiono per sito con un link alla fonte.

Fonte: Patchstack, “WordPress 7.1.4 Security Release”, 28 ottobre 2026, patchstack.com. Avviso di sfruttamento di Wordfence, 29 ottobre 2026, riportato da SecurityOnline; dato sulle 24 ore riportato da CyberPress, 31 ottobre 2026. Controllato il 31 ottobre 2026.