CVE-2026-119977 è una vulnerabilità del core di WordPress che interessa un momento preciso della manutenzione: l'aggiornamento del CMS. Se la nuova versione viene estratta in una cartella temporanea raggiungibile dal web, un attaccante senza credenziali può tentare di sfruttare una race condition per eseguire codice sul server. Il 3 novembre 2026 la CISA ha inserito la falla nel catalogo Known Exploited Vulnerabilities (KEV), riconoscendo che viene sfruttata in attacchi reali.

La correzione è già disponibile in WordPress 7.1.4, rilasciato il 28 ottobre. È una vicenda interessante soprattutto per chi gestisce più siti: il processo usato per installare una patch, normalmente considerato una misura di sicurezza, può diventare esso stesso una superficie d'attacco.

Una vulnerabilità che compare solo durante l'aggiornamento

WordPress deve scaricare, decomprimere e sostituire i file del core quando esegue un aggiornamento completo (full-package upgrade). Nelle versioni interessate, parte del contenuto del pacchetto veniva collocata temporaneamente in una directory prevedibile all'interno di wp-content/upgrade.

Il problema nasce dalla combinazione di tre proprietà:

  • la directory di staging può essere raggiungibile via HTTP in configurazioni comuni;
  • il percorso temporaneo è sufficientemente prevedibile da poter essere cercato;
  • durante l'estrazione possono essere presenti file eseguibili, compresi componenti dell'installazione di WordPress, prima che l'aggiornamento sia completato e i file temporanei vengano rimossi.

Un visitatore anonimo non dovrebbe poter interagire con questi file di lavoro. Se riesce a intercettare il breve intervallo in cui sono disponibili, in determinate condizioni può arrivare all'esecuzione remota di codice (RCE). La descrizione tecnica è riportata nell'advisory ufficiale del progetto WordPress.

La presenza di un WordPress vulnerabile, quindi, non significa che sia possibile sfruttare la falla in qualunque momento. Servono un aggiornamento completo in corso, accesso web alla directory temporanea e il tempismo necessario. Queste condizioni rendono l'attacco meno banale, ma non lo rendono trascurabile.

Perché si parla di race condition TOCTOU

La debolezza è classificata come CWE-367, una race condition time-of-check to time-of-use (TOCTOU). Il software controlla uno stato e compie un'azione in un momento successivo, assumendo che le condizioni rilevanti non siano cambiate nel frattempo.

Nel caso di WordPress, il nodo operativo è la transizione tra file del pacchetto ancora in fase di preparazione e file che verranno usati dal sistema. Se una risorsa temporanea viene esposta al web prima che l'aggiornamento abbia completato il suo ciclo, l'attaccante può cercare di accedervi durante quella finestra.

Immaginiamo un sito che riceve un aggiornamento automatico del core durante la notte. L'amministratore non è collegato, il sito può continuare a rispondere alle richieste e i file temporanei vengono creati e rimossi in pochi istanti. Un attaccante che interroga ripetutamente percorsi riconducibili all'aggiornamento cerca proprio di intercettare quel passaggio.

Questo esempio descrive il meccanismo generale, non una prova che ogni aggiornamento automatico sia stato compromesso. Per confermare un'intrusione servono evidenze sui log, sui file e sulle attività successive.

La conferma CISA e la gravità effettiva

La vulnerabilità ha identificativo CVE-2026-119977 e un punteggio CVSS 3.1 di 8,1/10 (High). Il vettore di valutazione prevede accesso tramite rete, nessuna autenticazione e nessuna interazione dell'utente, ma segnala anche un'elevata complessità d'attacco: cogliere la finestra temporale è parte della difficoltà.

La cronologia verificabile è breve:

  • 28 ottobre 2026: WordPress pubblica la release di sicurezza 7.1.4, contenente la correzione.
  • 31 ottobre: viene pubblicato il record CVE assegnato da Wordfence.
  • 3 novembre: CISA inserisce CVE-2026-119977 nel database KEV, riservato alle vulnerabilità per le quali esistono evidenze di sfruttamento.
  • 6 novembre: scadenza indicata dalla CISA per gli interventi delle agenzie federali civili statunitensi soggette alle direttive applicabili.

L'inserimento nel catalogo KEV della CISA è un'informazione più concreta di un semplice punteggio CVSS. Resta però importante leggere correttamente la telemetria: migliaia di richieste dirette a un percorso sospetto possono rappresentare tentativi o scansioni, non migliaia di compromissioni riuscite. La CISA non attribuisce pubblicamente questi attacchi a un gruppo specifico nel record KEV e indica come sconosciuto l'impiego della falla in campagne ransomware.

Quali installazioni WordPress devono essere controllate

Il record CVE descrive un intervallo ampio, dalla famiglia 4.7 fino a WordPress 7.1.3, con varianti vulnerabili nei singoli rami. Per il ramo attuale la versione corretta è 7.1.4. WordPress ha annunciato anche backport di sicurezza verso le famiglie più vecchie, da verificare sui rispettivi canali di rilascio: non bisogna presumere che qualunque versione 6.x sia automaticamente protetta.

La prima verifica può essere effettuata dal pannello Bacheca → Aggiornamenti. Dove è disponibile WP-CLI, i comandi seguenti permettono di leggere versione, aggiornamenti proposti e integrità dei file del core, senza eseguire un upgrade:

wp core version
wp core check-update
wp core verify-checksums

I comandi vanno eseguiti nella directory dell'installazione WordPress, con l'utente e i permessi appropriati. Il controllo dei checksum è utile anche dopo un aggiornamento, ma non costituisce da solo un'indagine forense completa: un aggressore potrebbe aver modificato plugin, temi, upload, utenti o file esterni al core.

Per installazioni gestite da hosting condivisi, è necessario verificare anche la versione effettivamente in esecuzione, non soltanto la presenza di un aggiornamento pianificato dal provider.

Come ridurre il rischio durante l'upgrade

Aggiornare WordPress resta la misura principale. Il fatto che la vulnerabilità riguardi la fase di aggiornamento non è un motivo per rimandare indefinitamente la patch: lasciare il core vulnerabile espone anche i successivi aggiornamenti completi. Per le installazioni critiche conviene affiancare alla correzione un controllo sul server web, eseguendo prima backup e verifiche di compatibilità.

Bloccare l'accesso HTTP alla directory temporanea

I file di staging dell'aggiornamento devono essere gestiti dal processo PHP sul filesystem, non consultati da visitatori anonimi. Un ulteriore controllo può impedire al server web di servire richieste dirette a wp-content/upgrade.

Un esempio di regola Nginx da adattare e testare all'interno del relativo blocco server è:

location ^~ /wp-content/upgrade/ {
    return 403;
}

Il modificatore ^~ è importante quando esistono location generiche per l'esecuzione dei file PHP: impedisce che una regola regex successiva prevalga sul blocco della directory. Dopo aver modificato la configurazione, è necessario validarla e applicarla secondo le normali procedure di change management, con possibilità di rollback.

Per Apache 2.4, il concetto equivalente può essere applicato nella configurazione del virtual host, non all'interno di un normale file .htaccess:

<LocationMatch "^/wp-content/upgrade/">
    Require all denied
</LocationMatch>

Il controllo va verificato anche in presenza di CDN, proxy o regole di routing personalizzate. Bloccare un percorso web non deve impedire al processo di aggiornamento di scrivere i file necessari nel filesystem: le due operazioni sono distinte.

Queste regole sono difese aggiuntive e non sostituiscono la patch ufficiale. Possono inoltre richiedere adattamenti in ambienti gestiti o con configurazioni Apache/Nginx non standard.

Evitare interventi alla cieca sui siti in produzione

Prima di aggiornare un'installazione importante, verifica che siano disponibili un backup ripristinabile e un metodo per controllare l'esito. È preferibile eseguire l'intervento in una finestra di manutenzione nota, monitorando contemporaneamente log di accesso, errori applicativi ed eventuali alert WAF.

Una regola CDN che blocca richieste anonime verso percorsi temporanei può fornire un'ulteriore barriera. Va però verificato il comportamento del proxy: un sito che restituisce una pagina di errore generica a tutti i crawler non migliora la propria sicurezza operativa.

Quali tracce cercare nei log

Una caratteristica di questo scenario è che l'attacco può produrre richieste ripetute a file PHP all'interno della directory di upgrade, soprattutto durante o poco prima dell'installazione di nuove versioni.

Su un server Nginx con log nel formato standard si può iniziare da una ricerca di sola lettura:

zgrep -E 'wp-content/upgrade/.*\.php' /var/log/nginx/access.log*

Adatta il percorso ai log effettivi del tuo hosting. Controlla poi il periodo degli aggiornamenti, lo status HTTP delle richieste, gli indirizzi IP, i pattern temporali e le eventuali regole WAF attivate.

Una richiesta con risposta 404 o 403 può essere un tentativo fallito o una scansione automatizzata. Una risposta 200 su un file che non avrebbe dovuto essere pubblicamente accessibile richiede un approfondimento, ma non prova da sola che sia stato eseguito codice arbitrario.

Se emergono indicatori concreti, controlla inoltre:

  • file PHP nuovi o modificati in percorsi non previsti, inclusi upload e cartelle temporanee;
  • creazione di amministratori, modifiche a ruoli, plugin o impostazioni sensibili;
  • cron e task schedulati inattesi, accessi SSH anomali e connessioni verso destinazioni sconosciute;
  • differenze rispetto a copie e checksum affidabili, senza cancellare prima le evidenze.

In caso di compromissione confermata, occorre valutare l'intero account di hosting, le credenziali del database e i segreti accessibili al processo PHP. Aggiornare soltanto il core potrebbe non rimuovere una persistenza installata in precedenza.

Dopo la patch: cosa verificare

Il controllo finale dovrebbe confermare versione effettiva corretta, integrità dei file, disponibilità del sito e assenza di anomalie. Verifica homepage, login, amministrazione, form e funzionalità dei plugin. Se hai introdotto un blocco web della directory di staging, assicurati che l'aggiornamento possa comunque completarsi e che la directory non sia accessibile anonimamente.

Le istanze che eseguono versioni molto vecchie meritano attenzione particolare: il fatto che una patch sia stata retroportata non equivale a supporto completo e continuativo dell'intero ramo. La migrazione verso una versione mantenuta rimane la scelta più prudente. Per altri controlli sul CMS, dalla gestione dei privilegi ai backup, è disponibile anche la guida F-Hack alla sicurezza di WordPress.

Una precisazione finale: CVE-2026-119977 riguarda il processo di aggiornamento del core, mentre altre vulnerabilità WordPress del 2026, come la catena wp2shell, coinvolgono percorsi di attacco differenti. Non vanno confuse durante l'analisi dei log o nella scelta della remediation.

Fonti primarie

La lezione tecnica riguarda il confine tra file di lavoro e contenuti serviti sul web: le directory temporanee create da un software in manutenzione non dovrebbero diventare endpoint accessibili a utenti non autenticati.