CVE-2026-119977: Flaw nella RCE del Core di WordPress Sfruttata Durante gli Aggiornamenti Software

Una vulnerabilità di alta gravità in WordPress Core viene attivamente presa di mira in attacchi, spingendo l’Agenzia statunitense per la sicurezza informatica e la sicurezza delle infrastrutture (CISA) ad aggiungere il difetto al suo catalogo di vulnerabilità sfruttate conosciute (KEV). Tracciata come CVE-2026-119977, la vulnerabilità porta un punteggio di CVSS di 8.1 e può consentire a un attaccante non autenticato di eseguire codice arbitrario su un server vulnerabile durante un aggiornamento di WordPress Core.

La vulnerabilità deriva da una condizione di gara time-of-check time-of-use (TOCTOU) nel processo di aggiornamento di WordPress. Durante gli aggiornamenti completi del Core, WordPress prepara temporaneamente i file di installazione in posizioni prevedibili e accessibili via web. Gli attaccanti possono sondare ripetutamente queste posizioni e tentare di accedere ai componenti di installazione durante il breve periodo in cui è in corso un aggiornamento.

WordPress ha affrontato la questione nella versione 7.1.4, rilasciata il 28 ottobre 2026. La vulnerabilità riguarda le versioni di WordPress dalla 4.7 alla 7.1.3, mentre le correzioni di sicurezza sono state anche retroportate nei rami più anziani idonei. WordPress sottolinea che solo l’ultima release è attivamente supportata.

Il rischio è andato oltre lo sfruttamento teorico. La telemetria di Wordfence citata da The Hacker News ha registrato oltre 18.500 richieste mirate ai percorsi dell’installer setup-config.php mentre i dati erano in fase di configurazione nei primi 21 ore dopo la divulgazione. CISA ha successivamente confermato prove di sfruttamento e ha richiesto alle agenzie federali civili statunitensi di risolvere la vulnerabilità entro il 6 novembre 2026.

I team di sicurezza possono utilizzare la SOC Prime Platform per rafforzare la copertura di rilevamento contro le tecniche di sfruttamento emergenti e cercare attività sospette associate a sistemi vulnerabili esposti a internet. Rileva lo sfruttamento di CVE-2026-119977 monitorando richieste anomale a luoghi di aggiornamento di WordPress, esecuzione inaspettata di PHP, creazione di nuovi account amministrativi, file sospetti e comportamento post-sfruttamento.

I contenuti di rilevamento potrebbero non essere disponibili per ogni CVE. Controlla la SOC Prime Platform per la copertura attuale. Se i rilevamenti pertinenti non sono ancora disponibili, controlla di nuovo poiché nuove informazioni sulle minacce e contenuti di rilevamento vengono continuamente aggiunti.

Contatta le Vendite

Analisi CVE-2026-119977

CVE-2026-119977 è classificato come una condizione di gara TOCTOU sotto CWE-367 e ha un punteggio CVSS 3.1 di 8.1. Il suo vettore riflette uno sfruttamento basato sulla rete che non richiede privilegi o interazione dell’utente, con un impatto potenziale elevato su riservatezza, integrità e disponibilità. La complessità dell’attacco è valutata alta perché lo sfruttamento riuscito dipende dal raggiungimento di una risorsa vulnerabile durante una stretta finestra di aggiornamento.

CVE-2026-119977 riguarda le release di WordPress Core dalla versione 4.7 alla 7.1.3. La debolezza non è legata a un plugin di terze parti o a un tema; esiste nel meccanismo di aggiornamento del software Core stesso.

Il problema si verifica durante gli aggiornamenti completi del pacchetto Core. WordPress estrae temporaneamente il nuovo pacchetto in una posizione di staging sotto la directory wp-content/upgrade prima di sostituire l’installazione esistente. Nelle release interessate, porzioni di questa posizione di staging possono essere prevedibili e raggiungibili dal web mentre l’aggiornamento è in corso.

Un componente particolarmente importante è l’installer setup-config.php in fase di staging. Un attaccante non autenticato che predice correttamente il percorso temporaneo e raggiunge quel componente prima che WordPress completi la pulizia potrebbe essere in grado di interagire con l’installazione in fase e, in definitiva, eseguire codice PHP sul server.

Questo crea un modello di sfruttamento insolito. Un sito WordPress vulnerabile non è necessariamente continuamente sfruttabile. Invece, l’attaccante deve cogliere il sito durante il breve periodo in cui un aggiornamento completo del pacchetto espone i file di staging. I ricercatori indicano che l’opportunità potrebbe durare solo pochi secondi.

Gli attaccanti possono compensare questa limitazione attraverso l’automazione. Invece di fare una singola richiesta, gli attori della minaccia possono continuamente sondare i potenziali percorsi di aggiornamento e attendere che un obiettivo inizi l’aggiornamento. Wordfence ha osservato attaccanti richiedere ripetutamente variazioni delle posizioni degli installer in fase di staging, dimostrando che gli attori del mondo reale hanno rapidamente compreso come mirare alla condizione di gara.

Il grande volume di richieste osservate dovrebbe comunque essere interpretato con attenzione. Le cifre riportate rappresentano richieste bloccate o tentativi di sfruttamento e non significano che ogni richiesta abbia portato a un’effettiva esecuzione remota di codice. Lo sfruttamento richiede ancora che la richiesta coincida con un aggiornamento completo del pacchetto attivo e altre condizioni richieste del server.

La telemetria iniziale di Wordfence ha mostrato più di 18.500 richieste contro i percorsi degli installer in fase di staging nelle prime 21 ore. GBHackers ha successivamente riportato quasi 59.000 tentativi bloccati in un periodo di 24 ore, mentre The Hacker News ha citato ulteriori telemetrie che dimostrano un’attività di sfruttamento continua.

La telemetria di honeypot indipendente citata da The Hacker News ha registrato tentativi di sfruttamento il 30 ottobre, sostenendo ulteriormente la decisione di CISA di classificare la vulnerabilità come attivamente sfruttata. L’aggiunta del difetto al KEV da parte di CISA aumenta significativamente l’urgenza per le organizzazioni che gestiscono infrastrutture pubbliche di WordPress.

Al momento della stesura, le fonti esaminate non documentano un repository PoC CVE-2026-119977 ampiamente disponibile e pubblicamente convalidato. Tuttavia, il codice exploit pubblico non è necessario per stabilire il rischio poiché tentativi di sfruttamento sono già stati osservati su larga scala e CISA ha confermato sfruttamento attivo.

WordPress 7.1.4 cambia il processo di aggiornamento vulnerabile. Secondo i rapporti tecnici disponibili, la mitigazione include rendere le posizioni di staging meno prevedibili, introdurre protezioni aggiuntive contro l’accesso diretto e prevenire che i dati di configurazione in stadio vengano promossi in modo non sicuro.

WordPress ha accreditato il ricercatore di sicurezza Umut Bayram per aver segnalato la debolezza del processo di aggiornamento. La versione 7.1.4 è stata rilasciata il 28 ottobre 2026 e il record CVE è stato successivamente pubblicato il 31 ottobre.

Per il rilevamento di CVE-2026-119977, i difensori dovrebbero prestare particolare attenzione alle richieste web che mirano a percorsi insoliti sotto wp-content/upgrade, in particolare richieste che fanno riferimento a copie in stadio di setup-config.php. Richieste ripetute attraverso più possibili directory di staging possono indicare sondaggio automatizzato che tenta di vincere la condizione di gara.

Lo sfruttamento riuscito può potenzialmente fornire l’esecuzione remota di codice PHP nel contesto del server web interessato. I difensori dovrebbero quindi correlare richieste sospette ai percorsi di aggiornamento con prove successive come file PHP inaspettati, modifica di dati di configurazione di WordPress, account amministrativi sconosciuti, plugin dannosi, processi figlio insoliti generati dal server web o connessioni in uscita inaspettate.

I rapporti pubblici non hanno identificato un set completo di IOC CVE-2026-119977 specifici dell’attaccante, come domini di comando e controllo stabili o hash di malware. Questo rende particolarmente importante il rilevamento basato su comportamento. Richieste a percorsi di staging prevedibili, attività sospette durante una finestra di aggiornamento e modifiche post-sfruttamento offrono più opportunità di caccia durature rispetto al fare affidamento esclusivamente su indicatori statici.

Mitigazione CVE-2026-119977

La principale mitigazione per CVE-2026-119977 è aggiornare immediatamente WordPress. WordPress 7.1.4 contiene la correzione di sicurezza e le correzioni sono state anche rese disponibili o retroportate per i rami più anziani idonei. Le organizzazioni dovrebbero dare priorità alla migrazione verso l’ultima versione di WordPress attivamente supportata piuttosto che fare affidamento indefinitamente su retroporti di sicurezza ereditati.

Gli amministratori devono intraprendere le seguenti azioni:

1. Aggiornare le installazioni di WordPress esposte a internet alla versione 7.1.4 o successiva.
2. Verificare che gli aggiornamenti automatici siano stati completati con successo piuttosto che presumere che un aggiornamento sia stato applicato.
3. Inventariare installazioni di WordPress più vecchie, inclusi siti di sviluppo, staging e legacy dimenticati.
4. Esaminare i log del server web e del WAF per richieste che mirano a wp-content/upgrade e a percorsi di setup-config.php in fase di staging.
5. Indagare sui file PHP inaspettati, nuovi account amministrativi di WordPress, plugin non autorizzati e modifiche di configurazione non spiegate.
6. Esaminare le connessioni in uscita e i processi figlio del server web per evidenze di attività post-sfruttamento.
7. Assicurarsi che le protezioni WAF operino sufficientemente presto nel percorso di richiesta per coprire richieste dirette a file PHP temporanei.
8. Considerare di limitare l’accesso web diretto a directory di aggiornamento temporanee dove operativamente possibile.

Le regole del firewall per applicazioni web possono ridurre l’esposizione ai tentativi di sfruttamento automatizzati, ma non dovrebbero essere trattate come un sostituto della patch. Poiché la risorsa vulnerabile può esistere temporaneamente al di fuori del normale flusso di richieste di WordPress, gli amministratori dovrebbero verificare che la loro distribuzione WAF ispezioni effettivamente le richieste dirette ai file PHP in fase di staging.

Le organizzazioni che hanno aggiornato mentre lo sfruttamento attivo era già in corso dovrebbero anche considerare un’indagine retrospettiva. Completare l’aggiornamento rimuove il comportamento vulnerabile ma non prova che il server non sia stato compromesso mentre la directory di staging vulnerabile era disponibile.

Rivedere i log di accesso intorno al preciso timestamp di aggiornamento. Le richieste ai percorsi di staging interessati che si verificano immediatamente prima o durante l’aggiornamento dovrebbero ricevere un’attenzione aggiuntiva. I team di sicurezza dovrebbero quindi correlare quelle richieste con cambiamenti del file-system, modifiche di account di WordPress, esecuzione PHP, connessioni di rete sospette e altri indicatori di post-sfruttamento.

Se si sospetta una compromissione, isolare l’host interessato dove praticabile, preservare i log web, dell’applicazione, di autenticazione e di sistema rilevanti, e raccogliere file sospetti prima della mitigazione. Credenziali e segreti accessibili al processo WordPress/PHP dovrebbero essere considerate potenzialmente esposte e ruotate in base ai risultati dell’indagine.

L’inclusione della vulnerabilità nel KEV da parte di CISA conferma che la mitigazione dovrebbe essere trattata come una priorità operativa immediata piuttosto che un elemento di un ciclo di patch di routine. Alle agenzie del ramo esecutivo civile federale è stato ordinato di affrontare la questione entro il 6 novembre 2026.