WordPress, CVE-2026-119977: CISA conferma lo sfruttamento attivo

Il 3 novembre 2026 la CISA, l’agenzia statunitense per la cybersicurezza, ha aggiunto al catalogo Known Exploited Vulnerabilities (KEV) la CVE-2026-119977, una race condition di tipo time-of-check time-of-use (TOCTOU) nel core di WordPress. È la falla del processo di aggiornamento corretta con WordPress 7.1.4, di cui abbiamo scritto il 30 ottobre, quando non aveva ancora un identificativo e si conoscevano solo i tentativi di attacco osservati da Wordfence. L’inserimento nel catalogo KEV indica che la CISA ha prove di sfruttamento attivo. Il 4 novembre anche il NCSC-NL, il centro nazionale per la cybersicurezza dei Paesi Bassi, ha pubblicato un avviso sulla vulnerabilità.

Cosa aggiungono gli avvisi

Secondo la scheda della National Vulnerability Database (NVD), a cui rimanda la voce del catalogo KEV, WordPress Core è vulnerabile all’esecuzione di codice da remoto nelle versioni dalla 4.7 alla 7.1.3. La causa sono i percorsi di staging prevedibili e raggiungibili dal web che WordPress usa durante gli aggiornamenti del core con il pacchetto completo: un attaccante senza autenticazione può eseguire codice sul server mentre l’aggiornamento è in corso.

• CVE: CVE-2026-119977, pubblicata su NVD il 31 ottobre 2026, analizzata il 4 novembre.
• Debolezza: CWE-367 (Time-of-check Time-of-use Race Condition).
• CVSS 3.1: 8.1, gravità alta, assegnato da Wordfence, vettore CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H: attacco via rete, complessità elevata, nessun privilegio e nessuna azione dell’utente richiesti, impatto alto su riservatezza, integrità e disponibilità.
• Codice coinvolto: i riferimenti di NVD indicano, nella 7.1.3, i file class-core-upgrader.php, class-wp-upgrader.php e update-core.php in wp-admin/includes/, più wp-admin/setup-config.php; le correzioni della 7.1.4 sono in class-wp-upgrader.php e update-core.php.
• Catalogo KEV: aggiunta il 3 novembre 2026; per le agenzie federali statunitensi la scadenza per intervenire è il 6 novembre 2026. L’uso in campagne ransomware è indicato come «sconosciuto».
• MITRE ATT&CK: T1190 (Exploit Public-Facing Application).

Gli avvisi disponibili non descrivono la catena di attacco completa, non riportano indicatori di compromissione e non dicono chi stia sfruttando la falla.

Le versioni corrette, ramo per ramo

Il 30 ottobre sapevamo solo che la correzione era stata estesa ai rami precedenti, fino al 4.7. La scheda NVD elenca ora, per ogni ramo, la prima versione non vulnerabile:

• rami 4.x: 4.7.39, 4.8.34, 4.9.35;
• rami 5.x: 5.0.31, 5.1.28, 5.2.30, 5.3.27, 5.4.25, 5.5.24, 5.6.23, 5.7.21, 5.8.19, 5.9.20;
• rami 6.x: 6.0.18, 6.1.16, 6.2.15, 6.3.14, 6.4.14, 6.5.14, 6.6.11, 6.7.11, 6.8.12, 6.9.11;
• rami 7.x: 7.0.8, 7.1.4.

Un’installazione è vulnerabile se la sua versione è inferiore a quella indicata per il suo ramo. NVD non elenca versioni precedenti alla 4.7.

L’avviso del NCSC-NL

Dell’avviso NCSC-2026-0466 del NCSC-NL, intitolato «Kwetsbaarheid verholpen in WordPress Core» (vulnerabilità corretta in WordPress Core), abbiamo potuto leggere solo il titolo: il testo non era disponibile. Il titolo riporta la classificazione [L/H], che nello schema del NCSC-NL indica una probabilità di abuso bassa (L) e un danno possibile alto (H). La CISA, il giorno prima, aveva registrato lo sfruttamento attivo: chi stabilisce le priorità tenga conto di entrambe le indicazioni.

Impatto per le aziende europee e italiane

Con l’inserimento nel catalogo KEV la falla passa dai tentativi osservati da un fornitore di sicurezza a una vulnerabilità sfruttata riconosciuta da un ente governativo: in molti programmi di gestione delle vulnerabilità questo basta per trattarla con la massima priorità. L’attacco resta possibile solo durante un aggiornamento con il pacchetto completo, ma l’intervallo di versioni colpite, dalla 4.7 alla 7.1.3, comprende anche le installazioni vecchie che nessuno aggiorna più da tempo.

Per i soggetti che rientrano nella NIS2, la gestione delle vulnerabilità note fa parte delle misure di sicurezza richieste; la compromissione di un sito esposto va valutata per la notifica allo CSIRT Italia dell’ACN e, se nel database ci sono dati personali, per la notifica al Garante entro 72 ore prevista dal GDPR. Strutture sanitarie e pubbliche amministrazioni che usano WordPress per prenotazioni o moduli online dovrebbero partire da quei siti.

Cosa fare subito

1. Verifica la versione di ogni installazione WordPress, dalla bacheca o con wp core version, comprese quelle di test e quelle affidate a fornitori esterni, e confrontala con l’elenco per ramo.
2. Aggiorna alla release corretta del tuo ramo o alla 7.1.4, seguendo le indicazioni del produttore, come chiede la CISA. Se non è possibile applicare la correzione, la CISA indica di sospendere l’uso del prodotto.
3. Riprendi le misure dell’articolo del 30 ottobre: blocco dell’accesso web e dell’esecuzione PHP nella cartella di staging prima di aggiornare, ricerca nei log del server web delle richieste a setup-config.php fuori dal percorso normale, verifica dell’integrità con wp core verify-checksums.
4. Se trovi tracce: isola il sito, conserva i log, ripristina da una copia pulita, cambia password, credenziali del database e chiavi segrete, poi valuta gli obblighi di notifica.

Come aiuta ARXDOME

ARX Expose mostra quali servizi l’azienda espone su Internet e quali prodotti vi sono riconosciuti, compresi i siti WordPress dimenticati. ARX Shield tiene sotto controllo le vulnerabilità aperte delle macchine monitorate. ARX Sentry raccoglie log ed eventi dei server monitorati, utili per cercare le richieste ai percorsi di staging.

Ultimo aggiornamento: 4 novembre 2026