WordPress 7.1.4: race condition con RCE, già tentativi di attacco

📌 Sviluppi successivi: WordPress, CVE-2026-119977: CISA conferma lo sfruttamento attivo (3 novembre 2026)

Il 28 ottobre 2026 WordPress ha pubblicato la versione 7.1.4, che tra le altre correzioni chiude una race condition nel processo di aggiornamento del core sfruttabile senza autenticazione per eseguire codice da remoto. Secondo Defiant, l’azienda che sviluppa Wordfence, i primi tentativi di sfruttamento sono arrivati poche ore dopo il rilascio delle patch. La notizia è riportata da SecurityWeek, heise Security e The Hacker News; i dettagli tecnici che seguono vengono dall’articolo di SecurityWeek, che cita l’analisi di Defiant ed è l’unico testo completo che abbiamo potuto analizzare.

Cosa è successo

Durante un aggiornamento, WordPress scompatta i file della nuova versione in una cartella temporanea di appoggio (staging) prima di installarli. Secondo Defiant, il percorso di questa cartella è prevedibile e, su molti server, raggiungibile dal web. Per pochi secondi, finché WordPress non ripulisce i file temporanei, un attaccante che conosce o indovina il percorso può raggiungere i file appena scompattati, compresi quelli dell’installatore.

Quando le fonti sono state pubblicate non era ancora stato assegnato un CVE. Defiant classifica il difetto come ad alta gravità, ma con complessità d’attacco elevata.

Dettagli tecnici

• Prodotto: WordPress core, processo di aggiornamento.
• Versione corretta: 7.1.4; secondo SecurityWeek la correzione è stata riportata anche nei rami precedenti, fino al 4.7.
• Tipo: race condition con esecuzione di codice da remoto (RCE), senza bisogno di un account sul sito.
• Condizioni, secondo Defiant: un aggiornamento con il pacchetto completo, che contiene anche i file dell’installatore; accesso pubblico via web ed esecuzione PHP nella cartella di staging; un percorso di staging prevedibile o scoperto; il tempo di completare l’attacco prima che WordPress cancelli i file temporanei.
• Correzione: la 7.1.4 rende casuale il nome della cartella di staging, aggiunge un file indice di protezione e impedisce di promuovere in modo non sicuro i dati di configurazione presenti nella copia di staging.
• MITRE ATT&CK: T1190 (Exploit Public-Facing Application).

La finestra di sfruttamento si apre quindi solo mentre il sito si aggiorna con un pacchetto completo. Per questo, secondo Defiant, gli attaccanti interrogano di continuo i percorsi vulnerabili, nella speranza di capitare proprio in quei pochi secondi. Le richieste osservate puntano a setup-config.php, lo script con cui WordPress crea la configurazione iniziale, nella copia di staging. Le fonti disponibili non descrivono la catena completa che porta dal file raggiunto all’esecuzione di codice.

La 7.1.4 corregge in tutto 22 difetti di sicurezza, tra cui diversi XSS, problemi nella Interactivity API, una divulgazione di informazioni senza autenticazione e una debolezza di autorizzazione. Aggiorna inoltre i certificati radice inclusi, dopo la recente revoca di eMudhra.

Tentativi di sfruttamento: cosa dicono le fonti

Secondo Defiant, la prima richiesta intercettata dalla nuova regola del firewall Wordfence è arrivata nove minuti dopo la sua attivazione; nelle prime 21 ore la telemetria ha registrato oltre 18.500 richieste verso i percorsi di setup-config.php nella copia di staging. The Hacker News titola invece su quasi 63.000 tentativi in 24 ore: il testo dell’articolo non era disponibile e non sappiamo quali richieste siano state contate, quindi i due numeri non sono direttamente confrontabili. Anche heise Security riporta tentativi di sfruttamento osservati.

Wordfence non ha segnalato compromissioni riuscite.

Impatto per le aziende europee e italiane

WordPress è la base di molti siti aziendali, portali di servizio e negozi online, spesso gestiti da agenzie o fornitori di hosting. La complessità elevata riduce le probabilità di successo del singolo tentativo, ma la scansione è automatica e continua: ogni aggiornamento completo eseguito su un server dove la cartella di staging è raggiungibile dal web diventa un’occasione. Un attacco riuscito porta all’esecuzione di codice sul server, con accesso alle pagine, al database e ai dati inviati dai moduli.

Per i soggetti che rientrano nella NIS2, la compromissione di un sito esposto è un evento da valutare per la notifica allo CSIRT Italia dell’ACN; se nel database ci sono dati personali va considerata anche 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. Inventario: elenca tutte le installazioni WordPress dell’azienda, comprese quelle di test e quelle gestite da agenzie o fornitori esterni, e chiedi a questi ultimi una conferma scritta dell’aggiornamento.
2. Aggiorna alla 7.1.4, oppure alla release corretta del tuo ramo se usi una versione precedente. Controlla la versione dalla bacheca o con wp core version.
3. Blocca l’accesso web alla cartella di staging (buona pratica generale, non indicata dalle fonti). In WordPress gli aggiornamenti usano di norma wp-content/upgrade/: negare dal server web l’accesso HTTP e l’esecuzione PHP in quella cartella elimina la condizione dell’accesso pubblico, anche durante l’aggiornamento. Le fonti non dicono se l’aggiornamento alla 7.1.4, eseguito da una versione vulnerabile, apra a sua volta la finestra: per prudenza applica il blocco prima di aggiornare.
4. Controlla il WAF: se davanti ai siti c’è un web application firewall, verifica che le regole per WordPress siano aggiornate.
5. Cerca tracce nei log del server web: richieste a setup-config.php fuori dal percorso normale, in particolare sotto wp-content/upgrade/, e soprattutto risposte con codice 200 nei minuti di un aggiornamento.
6. Verifica l’integrità: wp core verify-checksums, modifiche recenti a wp-config.php, nuovi utenti amministratori, file PHP inattesi in wp-content/. 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. Con ARX Scout Assessment, su richiesta e con la tua autorizzazione, un vulnerability assessment non invasivo segnala software obsoleto e pannelli di amministrazione esposti. ARX Sentry raccoglie log ed eventi dei server monitorati, utili per cercare le richieste ai percorsi dell’installatore.

Ultimo aggiornamento: 30 ottobre 2026