Una vulnerabilità critica scoperta nel cuore stesso di WordPress sta mettendo a rischio milioni di siti in tutto il mondo, Italia compresa. La falla, identificata come CVE-2026-119977, permette a un attaccante non autenticato di eseguire codice sul server proprio durante la finestra di aggiornamento del software, nel momento in cui l'amministratore pensa di stare rendendo il proprio sito più sicuro. L'agenzia statunitense per la cybersecurity CISA ha confermato che la falla viene già sfruttata attivamente e ha imposto alle agenzie federali americane una scadenza di pochi giorni per applicare la correzione: il 6 novembre 2026.
Cos'è la vulnerabilità CVE-2026-119977
Il problema riguarda il nucleo stesso di WordPress, non un plugin o un tema di terze parti, e colpisce le versioni dalla 4.7.0 alla 7.1.3: una finestra temporale che comprende quindi anche installazioni piuttosto datate ancora online. Tecnicamente si tratta di una race condition di tipo TOCTOU (Time-Of-Check Time-Of-Use, catalogata come CWE-367), con un punteggio di gravità CVSS di 8,1 su 10. In pratica il sistema controlla una condizione di sicurezza e poi, in una finestra temporale successiva, usa quel controllo per eseguire un'azione: se un attaccante riesce a inserirsi esattamente in quell'intervallo, può alterare il risultato e far eseguire al server codice arbitrario, senza bisogno di alcuna credenziale. La correzione è arrivata con la versione 7.1.4, rilasciata a fine ottobre 2026: chi non ha ancora aggiornato resta esposto.
Come avviene l'attacco: la finestra di aggiornamento diventa un varco
Il meccanismo sfruttato dagli attaccanti è descritto dalla stessa CISA in termini precisi: durante un aggiornamento completo del nucleo di WordPress, il sistema crea temporaneamente dei percorsi di staging (le cartelle in cui vengono preparati i file del nuovo pacchetto) che sono prevedibili e accessibili via web. Un attaccante che conosce questi percorsi può colpire proprio durante i pochi secondi in cui l'aggiornamento è in corso, intercettando file di installazione come il classico setup-config.php e usandoli per eseguire codice sul server prima che la procedura si chiuda. Non serve un account sul sito: lo ha confermato anche Wordfence, la società di sicurezza specializzata in WordPress che ha reso pubblici i dettagli della falla nella settimana precedente alla conferma di CISA.
La conferma di CISA e la corsa contro il tempo
Il 3 novembre 2026 CISA ha aggiunto la CVE-2026-119977 al proprio catalogo delle vulnerabilità sfruttate attivamente (Known Exploited Vulnerabilities, KEV), lo strumento con cui l'agenzia segnala le falle per cui esiste evidenza concreta di attacchi in corso, non solo un rischio teorico. Nella propria nota CISA ha scritto che "WordPress Core contiene una vulnerabilità di tipo time-of-check time-of-use (TOCTOU) che potrebbe consentire ad attaccanti non autenticati di eseguire codice sul server durante la finestra di aggiornamento", precisando che il problema "è dovuto a percorsi di staging prevedibili e accessibili via web, utilizzati durante gli aggiornamenti completi del nucleo". Per le agenzie federali civili statunitensi (FCEB), l'inserimento nel catalogo KEV si traduce in un obbligo: correggere la falla entro il 6 novembre 2026. Per chiunque altro gestisca un sito WordPress, quella data è un riferimento utile anche se non vincolante.
I numeri dell'attacco: migliaia di tentativi in poche ore
I primi tentativi di exploitation individuati risalgono al 30 ottobre 2026, osservati da honeypot della società di threat intelligence Previdian e riconducibili a un indirizzo IP geolocalizzato nel Regno Unito. Da quel momento il ritmo degli attacchi è salito rapidamente: secondo i dati diffusi da Wordfence, nelle prime 21 ore successive alla divulgazione pubblica della falla sono state registrate oltre 18.500 richieste dirette proprio contro i percorsi di installazione temporanei creati durante l'aggiornamento. Wordfence ha riferito di aver bloccato, nelle sole ultime 24 ore al momento della sua analisi, 12.632 tentativi di attacco riconducibili a questa vulnerabilità. Numeri che danno la misura di quanto rapidamente, oggi, i criminali informatici riescano a trasformare la pubblicazione di una falla critica in una campagna di attacco automatizzata su scala.
Cosa devono fare amministratori, agenzie web e aziende
La prima e più urgente misura resta l'aggiornamento a WordPress 7.1.4, dove il problema è stato risolto alla radice. Per chi gestisce più siti, agenzie web comprese, vale la pena verificare che tutte le installazioni clienti, comprese quelle meno recenti o apparentemente "dimenticate", siano state effettivamente aggiornate: proprio le versioni più vecchie, risalenti fino alla 4.7.0, rientrano nel perimetro vulnerabile. Chi non può aggiornare immediatamente dovrebbe limitare l'accesso pubblico alle cartelle temporanee di aggiornamento (tipicamente sotto wp-content/upgrade/) tramite le regole del proprio web server o un plugin di sicurezza, e monitorare i log per richieste anomale verso file come setup-config.php durante le finestre di manutenzione. Vale infine la considerazione più generale che questa vicenda porta con sé: anche le procedure pensate per aumentare la sicurezza, come un aggiornamento software, possono introdurre una finestra di esposizione se non progettate con attenzione, e la velocità con cui gli attaccanti automatizzano la ricerca di questi varchi rende la tempestività della patch un fattore sempre più determinante.
Il commento di PINET
WordPress è il sistema di gestione dei contenuti più diffuso al mondo, e in Italia sostiene una quota amplissima di siti di piccole imprese, professionisti, associazioni ed enti locali che spesso non dispongono di un presidio tecnico interno dedicato alla sicurezza. Per questo tipo di realtà, una falla che si attiva proprio durante l'aggiornamento (l'operazione che in teoria dovrebbe proteggerle) rischia di passare inosservata fino a quando il danno è già fatto, specie sugli hosting condivisi dove gli aggiornamenti vengono spesso lanciati in automatico e senza controllo successivo. Difficilmente si tradurrà in un adempimento normativo cogente come accade per le agenzie federali statunitensi, ma è un buon banco di prova per la cultura della sicurezza digitale che il GDPR e la normativa NIS2 chiedono ormai anche alle organizzazioni di dimensioni medio-piccole: sapere quali CMS e quali versioni girano sui propri siti, e avere un canale affidabile per essere avvisati quando una falla di questo tipo viene scoperta. Un problema pratico, in questo senso, resta quello delle tante installazioni WordPress gestite da fornitori terzi o rimaste di fatto senza un responsabile dopo il cambio di un'agenzia web: casi in cui nessuno, finché non succede qualcosa, si sente davvero in carico di applicare la patch.
