WordPress: falla attiva mentre aggiorni, cosa fare

Cosa è successo

WordPress è il programma con cui è fatta una grande parte dei siti web. Il suo «core» è il nucleo, che si aggiorna da solo o con un clic.

Il 28 ottobre 2026 è uscita la versione 7.1.4, una versione di sicurezza (BleepingComputer). Corregge la CVE-2026-119977. Una CVE è il numero di catalogo con cui si identifica una falla. Questa riguarda il meccanismo di aggiornamento: in una finestra di tempo breve, chi attacca può far eseguire codice al server, senza password.

Il 3 novembre l'agenzia statunitense per la cybersicurezza (CISA) l'ha inserita nel catalogo KEV, l'elenco delle falle già sfruttate negli attacchi veri (data dal feed ufficiale CISA). Non ha descritto come vengono condotti gli attacchi. Le agenzie federali americane dovevano correggere entro il 6 novembre (scadenza anch'essa dal feed CISA).

A scoprire la falla è stato Umut Bayram, ricercatore di Picus Security (azienda di sicurezza informatica), che WordPress.org accredita nell'annuncio ufficiale. Riguarda le versioni da 4.7.0 a 7.1.3: lo dicono sia The Hacker News sia l'advisory ufficiale di sicurezza di WordPress (su GitHub). BleepingComputer non elenca le versioni.

Perché aggiornare può essere rischioso

Durante un aggiornamento con pacchetto completo, WordPress scompatta una copia della nuova versione, installer compreso, in una cartella temporanea dentro wp-content/upgrade. Il server di solito la rende raggiungibile dal web.

Se chi attacca scopre il nome della cartella e arriva all'installer prima che WordPress lo cancelli, può eseguire codice sul server (The Hacker News, da Picus).

Il paradosso: l'aggiornamento che installa la correzione gira ancora con il vecchio codice. Sui siti 5.9 o successivi quel codice dà alla cartella il nome del file scaricato, quindi il nome è prevedibile. Sui siti dalla 4.7 alla 5.8 aggiunge caratteri casuali: il nome si scopre solo se il sito lo rivela, per esempio in un messaggio d'errore. Gli aggiornamenti successivi usano nomi casuali.

Nei test di Picus la finestra durava pochi secondi. Gli aggiornamenti automatici in background usano lo stesso meccanismo. Il comando wp core update di WP-CLI non è una scorciatoia: usa la stessa cartella (The Hacker News).

I pacchetti parziali, pensati per una sola versione di partenza, espongono il sito solo se contengono i file dell'installer. Controllato scaricando i pacchetti dal servizio ufficiale di WordPress.org: né il parziale da 7.1.3 a 7.1.4 né quello da 7.0.7 a 7.0.8 (la versione di manutenzione che riceve chi è rimasto sul ramo 7.0) contengono i file dell'installer (wp-admin/install.php, setup-config.php): quella parte specifica del rischio non si applica ai due percorsi di aggiornamento automatico più comuni. Resta un'incognita dichiarata: se il pacchetto parziale fallisce, WordPress potrebbe ripiegare sul pacchetto completo, che li contiene sempre. Chi invece preme «Aggiorna ora» a mano per saltare direttamente dalla 7.0.7 alla 7.1.4 (invece di lasciarsi portare prima alla 7.0.8) riceve dal servizio di WordPress.org un pacchetto completo, con l'installer incluso: per questo salto manuale il rischio è quello descritto in questa pagina, non ridotto.

Gli attacchi: cosa si sa e cosa no

Wordfence, l'azienda di sicurezza per WordPress (con un firewall e un plugin) che ha assegnato la CVE, ha dichiarato di aver bloccato 13.095 attacchi in 24 ore (BleepingComputer, da un aggiornamento dell'avviso uscito nel fine settimana): è un conteggio che Wordfence aggiorna via via, quindi cresce di giorno in giorno e non va letto come un totale definitivo. Sono comunque tentativi bloccati dal suo firewall, non siti violati.

Secondo The Hacker News i tentativi sono cominciati nove minuti dopo che Wordfence ha attivato la sua regola, il giorno del rilascio. Due degli indirizzi da cui partivano più attacchi hanno sondato piccoli gruppi di siti per circa 14,5 ore: Wordfence lo legge come il tentativo di cogliere l'istante dell'aggiornamento.

Su repository pubblici di GitHub c'è dalla settimana del 2 novembre codice che i suoi autori definiscono un exploit (il programma che sfrutta la falla). Uno dice di funzionare anche su cartelle prevedibili: per The Hacker News non è stabilito.

Sulla gravità le fonti non concordano: Wordfence dà 8,1 su 10 (punteggio CVSS 3.1, confermato dal record ufficiale del CVE, che riporta anche la complessità d'attacco come «alta»); l'advisory ufficiale di sicurezza di WordPress, pubblicata su GitHub, la giudica invece «bassa»; l'annuncio pubblico su wordpress.org/news (un testo diverso da quell'advisory) non assegna nessun livello di gravità; BleepingComputer la definisce grave, pur notando che serve un attacco ad alta complessità.

Nessuna fonte letta dice quanti siti siano vulnerabili o già violati, né se ci siano siti italiani colpiti.

Cosa fare prima di aggiornare

Le indicazioni arrivano dal ricercatore che ha scoperto la falla, riportate da The Hacker News. Il team di sicurezza di WordPress (riportato da BleepingComputer) dice di aggiornare subito alla 7.1.4; CISA chiede di dare priorità alla correzione.

Chiudi prima l'accesso web alla cartella, poi aggiorna. Il comando dipende dal server: se non sai quale hai, chiedi al fornitore del tuo hosting.

1. Blocca l'accesso web a wp-content/upgrade. Su nginx: location ^~ /wp-content/upgrade/ { deny all; }. Su Apache: Require all denied in un blocco <Directory> di quella cartella, nella configurazione del sito.
2. Se puoi modificare solo il file .htaccess, aggiungi nella radice di WordPress, sopra le regole di WordPress: RedirectMatch 403 ^/wp-content/upgrade/.
3. Non mettere un file .htaccess dentro wp-content/upgrade: il vecchio aggiornamento svuota quella cartella prima di scompattare.
4. Controlla che una richiesta a /wp-content/upgrade/ risponda 403.
5. Aggiorna a 7.1.4 o alla versione corretta del tuo ramo. Se non puoi modificare il server, il ricercatore indica l'alternativa: dopo un backup di file e database, aggiorna a mano fuori dalla radice web, copiando i file del core senza toccare wp-config.php e wp-content, poi aggiorna il database.
6. Dopo l'aggiornamento cerca i segni indicati da Wordfence: richieste inattese a file PHP sotto wp-content/upgrade, amministratori sconosciuti, plugin che nessuno ha installato, file PHP in quella cartella.

Da dove vengono questi dati

Lette per intero sette fonti in due momenti: cinque ufficiali — l'annuncio di WordPress.org per la 7.1.4, la sua scheda di versione, la voce del catalogo CISA KEV, l'advisory di sicurezza di WordPress su GitHub e il record ufficiale del CVE (CVE.org/MITRE) — più due testate lette da una ricerca precedente, BleepingComputer (4 novembre 2026) e The Hacker News (6 novembre 2026), che a oggi non si riescono a riaprire (rispondono «accesso negato»).

Le fonti ufficiali confermano: la data di rilascio della 7.1.4 (28 ottobre), il nome del ricercatore (Umut Bayram, Picus Security), il meccanismo generale, il retroporto della correzione fino alla versione 4.7, le versioni colpite (4.7.0-7.1.3), la data d'inserimento nel catalogo CISA KEV (3 novembre), la scadenza per le agenzie federali USA (6 novembre), il punteggio CVSS 8,1 assegnato da Wordfence e il giudizio «bassa» dell'advisory ufficiale di sicurezza di WordPress.

Restano a sola fonte The Hacker News: il meccanismo esatto della cartella (nomi prevedibili o casuali a seconda della versione), la finestra di pochi secondi osservata da Picus, WP-CLI, i comandi di blocco indicati dal ricercatore, i «nove minuti» e le 14,5 ore di sondaggio, i repository GitHub con un presunto exploit, e i segni da controllare dopo un attacco. A sola fonte BleepingComputer: i 13.095 attacchi bloccati in 24 ore.

I comandi sono quelli del ricercatore; il blocco location di nginx va messo nel blocco server del sito e il server va ricaricato. Il percorso presume WordPress nella radice del sito.