WordPress sotto attacco: la falla nell'aggiornamento automatico che apre la porta agli hacker

Perché anche un aggiornamento automatico può lasciare la porta aperta per pochi secondi

Quando WordPress si aggiorna da solo, scarica il pacchetto della nuova versione e lo scompatta temporaneamente in una cartella del sito stesso, prima di installarlo in modo definitivo. Fino alla versione 7.1.3, questa cartella provvisoria si trovava in un percorso prevedibile, dentro wp-content/upgrade/, e per i pochi secondi in cui restava presente era raggiungibile da chiunque ne conoscesse il nome, anche senza essere autenticato sul sito. CVE-2026-119977 sfrutta esattamente questa finestra: un aggressore che individua quando un sito sta per aggiornarsi può interrogare ripetutamente quel percorso, in attesa del momento in cui i file temporanei compaiono sul server, e in quell'istante richiedere uno script di installazione rimasto momentaneamente accessibile per eseguire codice sul server.

Si tratta di una cosiddetta race condition, in gergo tecnico TOCTOU (time-of-check time-of-use): la vulnerabilità non dipende da una password debole o da un plugin non aggiornato, ma dal normale funzionamento dell'aggiornamento automatico, attivo di default su milioni di installazioni WordPress nel mondo. Non a caso l'attacco è difficile da realizzare, perché richiede di vincere una vera e propria corsa contro il tempo, ed è questo il motivo per cui WordPress nella propria valutazione interna classifica il rischio come basso. Wordfence, che ha scoperto e documentato la falla, assegna invece un punteggio di gravità di 8,1 su 10, perché se l'attacco riesce il risultato è l'esecuzione di codice da remoto senza alcuna credenziale: una differenza di giudizio che riflette due modi diversi di guardare allo stesso problema, la difficoltà tecnica da un lato e il danno potenziale dall'altro.

Cosa cambia con la versione 7.1.4 e perché la finestra temporale conta

WordPress ha chiuso il problema rendendo imprevedibile il nome della cartella temporanea di aggiornamento, ora generato con una stringa casuale di 16 caratteri, e bloccando l'esecuzione degli script di installazione eventualmente rimasti nella cartella. La correzione è stata applicata retroattivamente a tutte le versioni supportate, dalla 4.7.39 fino alla 7.1.4, pubblicate tutte il 28 ottobre 2026; restano scoperte, e non riceveranno patch, solo le installazioni precedenti alla versione 4.7, ormai molto rare.

Il 3 novembre CISA ha confermato lo sfruttamento attivo della falla e ha fissato al 6 novembre 2026 la scadenza per la messa in sicurezza dei sistemi delle agenzie federali statunitensi. È una scadenza che riguarda formalmente la pubblica amministrazione americana, ma segnala quanto la minaccia sia concreta anche per le aziende private: secondo i dati diffusi da Wordfence, nelle prime 21 ore dopo l'attivazione delle prime regole di protezione sono state registrate oltre 18.500 richieste indirizzate proprio ai percorsi temporanei di aggiornamento, segno che gli aggressori stanno scansionando la rete alla ricerca di siti ancora vulnerabili, in modo automatico e su larga scala.

I cinque controlli da fare subito

Per una PMI che gestisce un sito, un blog o un e-commerce su WordPress, la priorità non è capire i dettagli tecnici della falla, ma verificare rapidamente alcuni punti concreti.

• Controllare la versione installata. Dal pannello di amministrazione, sotto Bacheca > Aggiornamenti, verificare che WordPress sia alla versione 7.1.4 o successiva. Se il sito risulta fermo a una versione precedente, va aggiornato subito, perché fino alla 7.1.3 il problema è presente.
• Verificare che gli aggiornamenti automatici del nucleo siano attivi. Molti siti gestiti da agenzie o sviluppatori esterni hanno questa funzione disattivata per motivi di stabilità, oppure la disattivano configurazioni come AUTOMATIC_UPDATER_DISABLED nel file wp-config.php: in questi casi l'aggiornamento non arriva da solo e va installato manualmente, prima possibile.
• Ispezionare la cartella wp-content/upgrade. Dopo un aggiornamento recente, questa cartella dovrebbe risultare vuota o priva di file PHP sospetti o sconosciuti: la presenza di file di installazione residui, specie se accessibili dall'esterno, è un segnale da verificare con attenzione.
• Limitare l'accesso pubblico a wp-admin e alle cartelle di aggiornamento. Bloccare a livello di server web l'accesso diretto a wp-content/upgrade/ e restringere l'area di amministrazione, ad esempio per indirizzo IP o con un livello di autenticazione aggiuntivo, riduce in modo sensibile la superficie che un aggressore può sondare, anche in presenza di falle non ancora note.
• Affidare il controllo periodico a chi se ne occupa di mestiere. Molti di questi controlli vanno ripetuti nel tempo, non fatti una volta sola: un sito aggiornato oggi può tornare vulnerabile domani se un plugin blocca gli aggiornamenti automatici o se qualcuno disattiva una configurazione di sicurezza senza accorgersene.

Cosa può fare Hi-Keep

Hi-Keep segue da anni i siti e le applicazioni web di PMI italiane e può verificare, per il sito aziendale, la versione di WordPress installata, lo stato degli aggiornamenti automatici e la configurazione del server, oltre a mettere in sicurezza l'accesso alle aree amministrative e alle cartelle sensibili. Per chi non ha oggi un presidio tecnico continuo sul proprio sito, Hi-Keep può occuparsi del monitoraggio e degli aggiornamenti periodici, così da individuare situazioni come questa prima che diventino un incidente concreto. Chi gestisce un sito WordPress aziendale e vuole un controllo puntuale sulla versione installata e sulla configurazione di sicurezza può contattare Hi-Keep per una verifica mirata.