WordPress, la falla nell’aggiornamento del core è già sotto attacco: passate alla 7.1.4

Il 3 novembre 2026 CISA ha aggiunto al catalogo delle vulnerabilità sfruttate la CVE-2026-119977, una falla del core di WordPress corretta il 28 ottobre con la versione 7.1.4. Permette a un attaccante non autenticato di eseguire codice sul server durante la “finestra” di un aggiornamento completo del core. Sono colpite tutte le versioni dalla 4.7 alla 7.1.3.

Che cosa non va nell’aggiornamento

Quando WordPress installa un pacchetto completo del core, scompatta i file in cartelle di appoggio prima di copiarle al loro posto. Secondo la descrizione di Wordfence riportata da NVD, quei percorsi sono prevedibili e raggiungibili dal web: chi li indovina nel momento giusto può far eseguire codice al server. CISA la classifica come race condition “time-of-check time-of-use”. Il bug è stato segnalato da Umut Bayram, che BleepingComputer indica come ricercatore di Picus Security.

La 7.1.4 corregge 13 problemi in tutto, quasi tutti XSS memorizzati (Interactivity API, blocchi, Customizer, nomi utente) più un aggiornamento dei certificati radice inclusi. Il post ufficiale non indica CVE né parla di sfruttamento; precisa che i backport sui rami più vecchi «sono in corso» (traduzione nostra) e usciranno man mano. Per questo chi è fermo a un ramo precedente deve controllare quale release di sicurezza è disponibile per il proprio ramo, invece di dare per scontato un numero.

Quanti attacchi

CISA non ha dato dettagli. Secondo BleepingComputer, Wordfence ha aggiornato il proprio avviso indicando 13.095 attacchi bloccati in 24 ore contro questa falla. Altre testate hanno riportato cifre più alte su finestre temporali diverse, che non abbiamo potuto verificare sulla pagina di Wordfence. La falla non va confusa con la CVE-2026-87902, inclusione remota di file nel core entrata nel catalogo KEV il 25 settembre.

Cosa fare subito

1. Da Bacheca, Aggiornamenti, controllate di essere sulla 7.1.4 o sull’ultima release di sicurezza del vostro ramo. Con gli aggiornamenti automatici in background attivi dovrebbe essere già installata.
2. Se avete aggiornato a mano, o con gli aggiornamenti automatici disattivati, tra il 28 ottobre e l’installazione della patch, cercate file PHP estranei nella cartella di lavoro degli aggiornamenti (wp-content/upgrade/) e nella radice del sito.
3. Verificate l’integrità dei file del core e la lista degli amministratori: un utente creato di recente che non riconoscete è un segnale da non ignorare.
4. Per agenzie e chi gestisce molti siti: usate wp-cli su tutto il parco, sito per sito, dalla cartella di installazione.
5. Se trovate indizi di compromissione, cambiate password e chiavi in wp-config.php e ripristinate da un backup precedente al 28 ottobre.

wp core version
wp core update
wp core verify-checksums
wp user list --role=administrator --fields=ID,user_login,user_registered
find wp-content/upgrade -type f -name '*.php'

La nostra lettura

Il paradosso è evidente: la falla colpisce proprio il momento in cui si aggiorna. Chi ha gli aggiornamenti automatici attivi è passato alla 7.1.4 in poche ore; chi li ha spenti “per non rompere il sito” è il bersaglio ideale, perché aggiorna tardi e a mano. Il nostro consiglio resta lasciare attivi gli aggiornamenti di sicurezza del core. Altre allerte in https://hardwarfare.it/category/sicurezza-informatica/vulnerabilita-patch/; per proteggere gli account amministratore vale anche https://hardwarfare.it/guide/tutorial/passkey-phishing-guida-attivazione/.

Articolo redatto con il supporto di strumenti di intelligenza artificiale e verificato dalla redazione. Come usiamo l'AI · Come lavoriamo