CVE-2026-119977: RCE in WordPress Core sfruttata, come verificare e aggiornare a 7.1.4

Se hai un sito WordPress, questa settimana c'è una cosa sola da fare prima di tutto: controllare che il core sia aggiornato alla 7.1.4 o a una delle versioni di manutenzione con il fix. La vulnerabilità CVE-2026-119977 permette a un attaccante non autenticato di eseguire codice sul server durante la finestra di aggiornamento del core ed è già inserita nel catalogo CISA KEV, cioè è sfruttata attivamente. Qui trovi cosa è, chi è colpito, come verificare e come chiudere il problema.

Cosa è successo: la vulnerabilità CVE-2026-119977 in WordPress Core

CVE-2026-119977 è una race condition di tipo TOCTOU (time-of-check time-of-use) nel processo di aggiornamento di WordPress Core. Durante un aggiornamento completo del pacchetto core, WordPress scompatta i file in percorsi di staging prevedibili e raggiungibili via web. Tra il momento in cui i file vengono controllati e quello in cui vengono usati, un attaccante che conosce quei percorsi può interferire e ottenere l'esecuzione di codice sul server, senza bisogno di credenziali. Il difetto è stato corretto nella release di sicurezza WordPress 7.1.4 del 28 ottobre 2026, che il team descrive come "una debolezza nel processo di aggiornamento che può portare a remote code execution durante la finestra di upgrade". La pubblicazione della CVE è del 3 novembre 2026.

Chi è colpito: versioni vulnerabili di WordPress Core

Il problema è nel core, non in un plugin o in un tema. Riguarda quindi qualunque installazione WordPress self-hosted che esegue aggiornamenti completi del pacchetto, manuali o automatici. L'advisory Wordfence fa riferimento alle versioni da 4.7.0 a 7.1.3; WordPress.org conferma che i fix sono stati riportati su tutti i rami che ricevono ancora aggiornamenti di sicurezza, fino alla 4.7. In pratica:

• WordPress 7.1.3 e precedenti: vulnerabili, da aggiornare;
• WordPress 7.1.4: corretta;
• rami più vecchi (dalla 4.7 in poi): esiste una release di manutenzione con il backport, il numero esatto va verificato nella pagina degli aggiornamenti o sull'advisory ufficiale.

Chi usa hosting gestiti o WordPress.com deve comunque verificare la versione, perché non tutti i fornitori applicano le patch con la stessa velocità.

Quanto è grave: punteggio CVSS e sfruttamento attivo

Il punteggio CVSS non è ancora stato assegnato dal NVD. Conta però altro: CISA ha inserito la vulnerabilità nel catalogo Known Exploited Vulnerabilities, quindi esistono attacchi reali in corso, e ha fissato per le agenzie federali USA una scadenza di rimedio molto breve, il 6 novembre 2026. L'uso in campagne ransomware è al momento classificato come sconosciuto. Il risultato di uno sfruttamento riuscito è una remote code execution non autenticata: l'attaccante ottiene esecuzione di codice con i permessi dell'utente web, cioè accesso completo a file, database e credenziali del sito, con possibilità di installare webshell e muoversi verso altri siti sullo stesso server. La condizione limitante è che l'attacco deve avvenire durante la finestra di aggiornamento del core, ma gli aggiornamenti automatici in background rendono quella finestra prevedibile e frequente.

Come capire se sei esposto: verifica versione, esposizione e log

Verifica della versione di WordPress Core

• Bacheca, menu Aggiornamenti: la pagina mostra la versione installata e segnala se è disponibile la 7.1.4;
• da shell con WP-CLI: wp core version;
• senza WP-CLI: leggi la variabile $wp_version nel file wp-includes/version.php.

Fai il controllo su ogni installazione, inclusi siti di staging, sottodomini dimenticati e vecchie copie lasciate in sottocartelle: sono proprio quelle che nessuno aggiorna.

Esposizione dei percorsi di staging

Prova a richiedere dal browser la directory che WordPress usa per gli aggiornamenti, wp-content/upgrade, e verifica che non restituisca listati di file né file scaricabili. L'advisory Wordfence descrive nel dettaglio i percorsi coinvolti: confrontali con la tua configurazione.

Log e indicatori di compromissione

• nei log di accesso del web server cerca richieste verso wp-content/upgrade e verso file PHP in percorsi temporanei, soprattutto in corrispondenza degli orari degli aggiornamenti automatici;
• controlla la presenza di file PHP recenti e sconosciuti in wp-content/upgrade, wp-content/uploads e nella root;
• confronta i file del core con quelli originali: wp core verify-checksums;
• verifica utenti amministratori non previsti, plugin sconosciuti e attività pianificate (cron) anomale.

Questi controlli si integrano con quelli che ho descritto nell'articolo sui 10 controlli di sicurezza per un sito WordPress.

Come risolvere la vulnerabilità: patch, aggiornamento e rimedio

La patch esiste ed è WordPress 7.1.4. Si applica dalla Bacheca (Aggiornamenti, poi Aggiorna ora), con WP-CLI tramite wp core update, oppure scaricando il pacchetto da WordPress.org. Per i siti con aggiornamenti automatici attivi la release dovrebbe essere già installata: verifica comunque, perché un aggiornamento fallito a metà non è raro. Chi è rimasto su un ramo precedente può installare la release di manutenzione con il backport, ma ricordo che solo la versione più recente è supportata attivamente: la scelta giusta è portare il sito alla 7.1.4. Prima di aggiornare fai un backup completo di file e database e controlla la compatibilità di tema e plugin su una copia di staging. Oltre a CVE-2026-119977, la 7.1.4 chiude numerose stored XSS, un problema di denial of service nell'Interactivity API e un'esposizione di changeset non pubblicati del Customizer: ragione in più per non rimandare.

Cosa fare subito: mitigazioni e hardening

1. Aggiorna a 7.1.4 su tutti i siti, partendo da quelli raggiungibili da internet. È l'unico rimedio reale.
2. Se non puoi aggiornare entro poche ore, disattiva temporaneamente gli aggiornamenti automatici del core, per non aprire la finestra vulnerabile senza presidio, e pianifica l'aggiornamento manuale in un momento controllato.
3. Nega l'esecuzione di PHP e l'accesso web diretto a wp-content/upgrade tramite regole del web server (.htaccess su Apache, blocco di location su nginx). È una mitigazione, non sostituisce la patch.
4. Verifica che un WAF o le regole del firewall applicativo blocchino richieste anomale verso i percorsi di staging.
5. Dopo l'aggiornamento, ruota le credenziali: password degli amministratori, chiavi e salt in wp-config.php, password del database e delle API collegate.
6. Segmenta: se sullo stesso server girano più siti, isola i permessi tra le installazioni, così una compromissione non si propaga.

CISA chiede di applicare le mitigazioni del fornitore e, se non disponibili, di interrompere l'uso del prodotto. Per WordPress la mitigazione è disponibile: aggiornare.

Se sospetti una compromissione: incident response e analisi forense

Se trovi webshell, utenti sconosciuti o richieste sospette nei log, non ripulire alla cieca e non reinstallare subito sopra l'esistente. Le tracce servono per capire cosa è stato preso e per eventuali obblighi di notifica. I passaggi che seguo:

• non spegnere il server e non cancellare file: metti il sito in manutenzione o bloccalo a livello di firewall;
• preserva log del web server, log PHP, log di accesso al database e, se possibile, un'immagine della memoria e del disco (copia forense);
• cambia tutte le credenziali da una macchina pulita;
• ricostruisci il sito da un backup antecedente all'attacco, dopo averne verificato l'integrità, e aggiorna prima di rimetterlo online;
• se il sito tratta dati personali, valuta con il titolare del trattamento la notifica al Garante entro i termini del GDPR.

Per un intervento di incident response i miei preventivi a prezzo fisso vanno da 1.500 a 6.000 € in base all'estensione del danno; per gli interventi urgenti applico una maggiorazione del 50%.

Fonti ufficiali

• WordPress 7.1.4, note di rilascio
• Advisory Wordfence su CVE-2026-119977
• Scheda NVD CVE-2026-119977
• CISA BOD 26-04
• Guida di implementazione BOD 26-04

Verifica e patch per WordPress Core: come posso aiutarti

Se gestisci più siti WordPress e non sai da dove cominciare, posso fare la verifica delle versioni, applicare l'aggiornamento con backup e test, e controllare i log per escludere che qualcuno sia già passato. Chi ha un contratto di manutenzione con me riceve questi aggiornamenti come parte del servizio. Per tutti gli altri, chiedi un preventivo gratuito: rispondo entro 24 ore, anche via WhatsApp dalla pagina contatti.