WordPress, falla CVE-2026-119977 sfruttata: aggiornare il core in sicurezza

Il 28 ottobre 2026 WordPress ha pubblicato la versione di sicurezza 7.1.4, con correzioni portate su tutte le versioni precedenti fino alla 4.7. La più importante riguarda CVE-2026-119977: durante un aggiornamento del nucleo (core), un attaccante senza alcun account che riesce a intervenire nel momento giusto può arrivare a eseguire codice sul server. Il 3 novembre l’agenzia statunitense CISA ha inserito la falla nel catalogo delle vulnerabilità sfruttate (KEV), sulla base di prove di sfruttamento attivo.

Per una PMI ticinese con un sito WordPress la conseguenza pratica è semplice: il sito va portato alla versione corretta, e conviene verificare che non sia successo nulla di anomalo dal 28 ottobre in poi. C’è però un dettaglio che rende questo caso diverso dal solito: la falla sta proprio nel processo di aggiornamento.

Cosa è successo

Secondo l’avviso di sicurezza di WordPress (GHSA-4w3m-c66w-69mg, 29 ottobre 2026), durante un aggiornamento del core con pacchetto completo WordPress estraeva i nuovi file in una cartella con nome prevedibile all’interno della cartella wp-content/upgrade, raggiungibile dal web. Chi vince la «gara» contro questa estrazione, nei pochi istanti in cui la copia temporanea esiste, può arrivare all’esecuzione di codice. Sono interessate le versioni dalla 4.7 alla 7.1.3.

Le valutazioni di gravità divergono, e conviene capire perché:

• WordPress classifica la falla come di gravità bassa, perché la finestra utile è molto breve.
• Wordfence, che ha assegnato il CVE, le attribuisce un punteggio CVSS 3.1 di 8.1 (alto), come riportato dal database NVD: la complessità d’attacco è alta, ma se l’attacco riesce l’impatto sul server è totale.
• La CISA la considera sfruttata attivamente e il Centro canadese per la cibersicurezza ha diffuso un avviso il 3 novembre.

Secondo Wordfence, i primi tentativi sono iniziati il giorno stesso della pubblicazione e il suo firewall ne ha bloccati oltre 240'000. Wordfence precisa che riuscire nell’attacco è difficile nella pratica: i tentativi automatizzati ripetuti servono proprio a cogliere il breve momento dell’aggiornamento.

Il dettaglio da conoscere: l’ultimo aggiornamento

La correzione rende casuale il nome della cartella temporanea. Ma l’aggiornamento che installa la 7.1.4 viene eseguito ancora dal codice vecchio già presente sul sito: secondo Wordfence, il passaggio dalla versione vulnerabile a quella corretta apre quindi la finestra un’ultima volta, per la durata dell’aggiornamento. Dopo, gli aggiornamenti futuri non sono più interessati.

Questo non è un motivo per rimandare: Wordfence raccomanda di aggiornare il prima possibile. Come precauzione aggiuntiva indica di bloccare, a livello di server web, l’accesso ai file PHP nella cartella /wp-content/upgrade/ prima di aggiornare. WordPress scrive in quella cartella direttamente sul file system, quindi il blocco degli accessi dal web non impedisce l’aggiornamento.

Versioni corrette

Versioni indicate come corrette nell’avviso di WordPress (estratto; l’elenco completo comprende tutti i rami fino alla 4.7):

WordPress ricorda che è supportata attivamente solo la versione più recente: chi è ancora su un ramo vecchio dovrebbe pianificare il passaggio alla 7.1.

Cosa fare con il proprio sito WordPress

1. Verificare la versione. Nella bacheca, alla voce Aggiornamenti, oppure chiedendo al fornitore. Deve risultare la 7.1.4 o la versione corretta del proprio ramo. Gli aggiornamenti automatici in background di norma l’hanno già installata, ma va controllato: non sempre vanno a buon fine.
2. Se il sito non è ancora aggiornato: fare un backup di file e database, chiedere a chi gestisce il server di bloccare l’accesso web ai file PHP in /wp-content/upgrade/ e aggiornare subito.
3. Controllare i segnali di compromissione dal 28 ottobre. Nei log di accesso del server, richieste verso /wp-content/upgrade/ andate a buon fine; nella bacheca, account amministratore sconosciuti; sul server, file PHP inattesi o modifiche non pianificate a wp-config.php. La CISA prevede, per le proprie agenzie, proprio una verifica forense per questa falla.
4. Se emergono indizi: considerare il sito compromesso, isolarlo, cambiare le credenziali (amministratori, database, chiavi API), ripristinare da un backup pulito precedente al 28 ottobre e far analizzare il server. L’aggiornamento da solo non elimina ciò che un attaccante avesse già installato.
5. Plugin, temi e PHP. Approfittare dell’intervento per aggiornare anche plugin e temi e verificare la versione di PHP: a ottobre sono state corrette anche falle critiche in PHP e diversi plugin WordPress.

Non pubblichiamo dettagli su come sfruttare la falla: l’obiettivo è chiudere l’esposizione e verificare i sistemi.

Se il sito è stato compromesso: segnalazioni

• Protezione dei dati (nLPD). Se sul sito o sul server ci sono dati personali (moduli di contatto, account clienti, ordini) e la violazione comporta verosimilmente un rischio elevato per le persone interessate, l’articolo 24 della legge sulla protezione dei dati prevede la notifica all’IFPDT il prima possibile. Le linee guida dell’IFPDT spiegano come valutare il caso e notificarlo.
• UFCS. Per la maggior parte delle PMI la segnalazione di un ciberincidente all’UFCS è volontaria, ma utile. Dal 1° aprile 2025 i gestori di infrastrutture critiche hanno invece l’obbligo di segnalare i ciberattacchi entro 24 ore dalla scoperta.
• Danni finanziari. In caso di danno, sporgere denuncia alla polizia cantonale.

Domande frequenti

Il nostro sito si aggiorna da solo: dobbiamo fare qualcosa?

Secondo Wordfence, i siti con aggiornamenti automatici attivi dovrebbero essere già passati a una versione corretta. Conviene comunque verificare la versione installata e dare un’occhiata ai log dal 28 ottobre, perché l’ultimo aggiornamento è passato dal codice vecchio.

Perché WordPress la classifica come bassa e la CISA come sfruttata?

Le due valutazioni guardano a cose diverse: WordPress pesa la difficoltà di colpire la breve finestra di aggiornamento, la CISA la presenza di tentativi reali di sfruttamento. Per chi gestisce un sito la conclusione è la stessa: aggiornare e verificare.

Il sito è gestito da un’agenzia: cosa chiedere?

Tre domande bastano: quale versione di WordPress è installata, se l’accesso web a /wp-content/upgrade/ è bloccato e se i log dal 28 ottobre sono stati controllati. Chiedete una risposta scritta.

Abbiamo un firewall o un plugin di sicurezza: siamo protetti?

Non necessariamente. Wordfence spiega che l’attacco colpisce file che non caricano WordPress, per cui un plugin di sicurezza interno al sito li vede solo in configurazioni particolari. Il blocco a livello di server web e l’aggiornamento restano le misure principali.

Il nostro approccio

ElaraTeq Sagl supporta PMI e studi in Ticino nell’aggiornamento e nella verifica di siti WordPress, nella configurazione del server web e nell’hosting in Svizzera (hosting, consulenza). Per un controllo del vostro sito potete contattarci.

Fonti

• WordPress, WordPress 7.1.4, 28 ottobre 2026
• WordPress, GHSA-4w3m-c66w-69mg: A race condition during core updates that could lead to remote code execution, 29 ottobre 2026
• NIST NVD, CVE-2026-119977
• CISA, CISA Adds One Known Exploited Vulnerability to Catalog, 3 novembre 2026
• Canadian Centre for Cyber Security, WordPress security advisory (AV26-1117), 3 novembre 2026
• Wordfence, Attackers Actively Probing for Upgrade-Window RCE Vulnerability in WordPress Core, novembre 2026
• UFCS, Obbligo di segnalare ciberattacchi contro le infrastrutture critiche
• IFPDT, Linee guida sulla notifica di violazioni della sicurezza dei dati