Il 28 ottobre 2026 il progetto WordPress ha rilasciato la versione 7.1.4, che corregge una vulnerabilità del tutto particolare: non risiede in un plugin o in un tema, ma nel processo di aggiornamento del core. La falla, tracciata come CVE-2026-119977, consente a un attaccante non autenticato di ottenere l'esecuzione di codice sul server se riesce a colpire la breve finestra temporale in cui WordPress sta applicando un aggiornamento completo. Il 3 novembre la CISA l'ha inserita nel catalogo delle vulnerabilità sfruttate attivamente (KEV). È un caso utile da analizzare, perché rovescia un'abitudine consolidata: qui il momento più rischioso non è quando il sito è "vecchio", ma quando lo si sta aggiornando.

Cosa è successo

I fatti, incrociando le fonti consultate (CISA, Wordfence, The Hacker News e le analisi tecniche di Patchstack e Rescana):

  • Tipo di difetto: race condition di tipo TOCTOU (time-of-check to time-of-use, CWE-367) nel meccanismo di aggiornamento del core.
  • Causa: durante un aggiornamento con pacchetto completo, WordPress estrae i nuovi file in una cartella di staging prevedibile sotto wp-content/upgrade/, raggiungibile via web. Quella copia contiene anche il file di installazione (wp-admin/setup-config.php), che in quel contesto può essere eseguito senza la configurazione del sito in produzione.
  • Impatto: esecuzione di codice arbitrario sul server, senza account e senza interazione dell'utente. La complessità di attacco è alta, perché occorre sfruttare una finestra di pochi secondi; gli attaccanti compensano con un polling automatizzato continuo.
  • Gravità: Wordfence, che ha assegnato il CVE, indica CVSS 3.1 pari a 8,1 (alta). Il progetto WordPress, nel proprio avviso su GitHub, l'aveva invece classificata come bassa: la discrepanza è reale e va tenuta presente quando si decide la priorità.
  • Versioni coinvolte: dalla 4.7 alla 7.1.3. La correzione è nella 7.1.4 e nei rilasci di backport per i rami precedenti (7.0.8, 6.9.11 e così via, fino alla 4.7.39). Le versioni 4.6 e precedenti non ricevono più patch di sicurezza.
  • Sfruttamento: Wordfence ha registrato oltre 18.500 richieste verso i percorsi di staging nelle prime 21 ore dopo l'attivazione della propria regola firewall, con due grandi sorgenti che hanno interrogato piccoli gruppi di siti per circa 14 ore e mezza. Altre fonti riportano decine di migliaia di tentativi bloccati in 24 ore, ma le cifre non sono omogenee tra loro e vanno lette come ordine di grandezza. Al momento non risultano compromissioni riuscite confermate.
  • Fix tecnico: la 7.1.4 aggiunge 16 caratteri casuali al nome della cartella di staging, mantiene (e ricrea se manca) il file index.php nella cartella di upgrade ed esclude wp-config.php dai file promossi dall'area di lavoro.

La CISA ha fissato al 6 novembre la scadenza per le agenzie federali statunitensi. Quella scadenza non vincola le organizzazioni europee, ma è un indicatore di priorità piuttosto chiaro.

Perché questa falla è diversa dalle altre

Le vulnerabilità di WordPress di cui si parla più spesso riguardano plugin abbandonati o temi non aggiornati. Qui il difetto è nel core e si manifesta solo in una circostanza: l'aggiornamento completo. Ne derivano tre conseguenze pratiche.

La prima è che gli aggiornamenti automatici in background non sono neutri. Un sito configurato per aggiornarsi da solo è esposto proprio nel momento in cui lo fa, e, paradossalmente, chi ha aggiornamenti manuali e rari ha meno finestre di esposizione, ma resta vulnerabile finché non aggiorna. L'unico modo di chiudere il problema è aggiornare alla versione corretta, e nel frattempo togliere all'attaccante la possibilità di raggiungere la cartella.

La seconda è che un plugin di sicurezza può non vedere l'attacco. La richiesta malevola arriva a un file PHP in wp-content/upgrade/ senza caricare WordPress, quindi un firewall a livello di plugin può non intervenire, a meno di attivare la modalità che lo esegue prima del caricamento del core (per Wordfence, l'Extended Protection). Chi si affida solo al plugin, senza regole sul web server, ha una protezione parziale.

La terza è che la protezione migliore è anche la più semplice: negare l'accesso web a quella cartella. In condizioni normali contiene soltanto un file index.php vuoto, quindi bloccarla non rompe nulla.

Cosa significa per le aziende italiane

WordPress alimenta una quota molto ampia dei siti istituzionali e commerciali italiani: studi professionali, PMI, enti locali, scuole, testate, e-commerce basati su WooCommerce. In molte di queste realtà il sito è gestito da un fornitore esterno o da una web agency, con contratti che non prevedono un presidio sistematico degli aggiornamenti di sicurezza. È il quadro in cui una vulnerabilità sfruttata entro pochi giorni dalla patch diventa un rischio concreto.

Il rischio non è soltanto il sito deturpato o il malware per il posizionamento SEO. Un server WordPress compromesso può ospitare pagine di phishing con il dominio dell'azienda, esporre i dati dei moduli di contatto e dei clienti (con possibili obblighi di notifica ai sensi del GDPR, art. 33) e fungere da trampolino verso altri sistemi se l'hosting è condiviso o se il sito comunica con il gestionale. Per i soggetti che rientrano nel perimetro NIS2 (D.lgs. 138/2024), la gestione delle vulnerabilità e la sicurezza della catena di fornitura sono misure esplicitamente richieste: un sito pubblico lasciato senza aggiornamento, o affidato a un fornitore che non lo aggiorna, è difficile da difendere in una verifica. Il punto da portare ai fornitori è semplice: chi è responsabile dell'aggiornamento, entro quanti giorni, e con quale evidenza.

Un ulteriore elemento di attenzione riguarda il disallineamento tra i punteggi. Se il vostro processo di patching si basa solo sul punteggio indicato dal produttore (qui "basso"), questa falla sarebbe finita in coda; i dati di sfruttamento reale dicono l'opposto. Per questo conviene affiancare al CVSS un criterio basato sull'esposizione (sito raggiungibile da internet) e sull'evidenza di attacco (inserimento nel catalogo KEV).

Cosa fare subito

  • Verificare la versione installata: da WP-CLI wp core version, oppure dalla bacheca di amministrazione. Il minimo sicuro è la 7.1.4 o la versione corretta del proprio ramo (ad esempio 7.0.8, 6.9.11).
  • Bloccare l'accesso web a wp-content/upgrade/ a livello di web server o CDN, prima di aggiornare, e disattivare l'elenco delle directory. Su Apache la regola va nella configurazione del virtual host, perché WordPress ricrea la cartella a ogni aggiornamento. Rimuovere il blocco solo dopo aver confermato la versione corretta.
  • Aggiornare con wp core update --minor se si vuole restare sul proprio ramo, poi controllare l'integrità con wp core verify-checksums.
  • Controllare i log del web server per richieste a file PHP sotto wp-content/upgrade/, in particolare ripetute e vicine ai momenti di aggiornamento; verificare l'esistenza di amministratori sconosciuti (wp user list --role=administrator), plugin inattesi e file PHP anomali.
  • Se si usa Wordfence, attivare l'Extended Protection. Nota: la regola per la versione gratuita arriva soltanto il 27 novembre, quindi in questo intervallo il blocco sul web server è la misura principale.
  • Chiedere conferma scritta all'hosting o all'agenzia che tutti i siti gestiti girino su una build corretta, e censire i siti ancora sulla serie 4.6 o precedente: non esiste una patch e vanno migrati.
  • Sugli aggiornamenti automatici, valutare di eseguirli in finestre di manutenzione con la cartella di staging bloccata da regola, e non lasciare siti esposti con aggiornamenti disabilitati per mesi.

Questo caso nella serie WordPress del 2026

Non è il primo episodio dell'anno sul core di WordPress. A settembre avevamo trattato un'altra falla critica del core sfruttata poche ore dopo la patch, nell'articolo WordPress, RCE critica nel core sfruttata in poche ore. Il caso attuale riguarda un meccanismo diverso (l'aggiornamento stesso, non una funzione di runtime), ma conferma la stessa tendenza: i tempi tra patch e attacco si contano ormai in ore, e il margine per aggiornare "alla prossima manutenzione" si è ridotto in modo sostanziale.

In sintesi

CVE-2026-119977 è una race condition nell'aggiornamento completo del core WordPress, sfruttata attivamente e inserita nel catalogo KEV della CISA il 3 novembre. La cura è la versione 7.1.4 (o il backport del proprio ramo); nell'attesa, negare l'accesso web alla cartella wp-content/upgrade/ riduce in modo netto l'esposizione. Chi gestisce siti per conto terzi dovrebbe trattarla come una priorità di giornata, non di calendario.