WordPress sotto attacco: quasi 63.000 tentativi contro una falla RCE

🛡️ Executive Summary

• 62.969 tentativi di attacco rilevati e bloccati da Wordfence in 24 ore contro una vulnerabilità RCE nel sistema di aggiornamento di WordPress.
• La falla interessa il core fino alla versione 7.1.3 e permette potenzialmente l’esecuzione di codice senza autenticazione durante una breve finestra temporale.
• WordPress 7.1.4 corregge il problema. Sono disponibili patch anche per i rami precedenti fino alla serie 4.7.

WordPress è finito nel mirino di una nuova campagna di scansioni automatizzate che tenta di sfruttare una vulnerabilità nel processo di aggiornamento del CMS. La falla permette, in condizioni particolari, di eseguire codice PHP sul server senza possedere credenziali di accesso. Il problema ha attirato rapidamente l’attenzione degli attaccanti: Wordfence dichiara di aver bloccato 62.969 tentativi in appena 24 ore, mentre gli sviluppatori di WordPress hanno già distribuito una correzione con la versione 7.1.4, pubblicata il 28 ottobre 2026. Il rischio riguarda il software principale della piattaforma e non dipende dall’installazione di plugin vulnerabili. Il dato sugli attacchi documenta una pressione offensiva concreta, ma non dimostra che altrettanti siti siano stati compromessi.

La vulnerabilità sfrutta una finestra temporanea durante gli aggiornamenti

Il difetto interessa il funzionamento interno degli aggiornamenti completi di WordPress, precisamente il momento in cui il CMS estrae i file della nuova versione in una directory temporanea prima di sostituire quelli esistenti. Nelle versioni vulnerabili, questa operazione può utilizzare un percorso prevedibile all’interno di wp-content/upgrade, rendendo temporaneamente raggiungibile una copia dei file di installazione. Se il server consente l’accesso pubblico e l’esecuzione di PHP in quella posizione, un attaccante potrebbe interagire con il codice dell’installer prima della conclusione dell’aggiornamento, ottenendo potenzialmente una remote code execution senza autenticazione. La debolezza è riconducibile a una race condition, nella quale l’esito dell’attacco dipende dalla capacità di intervenire durante una fase molto limitata dell’operazione. Il problema è stato segnalato dal ricercatore Umut Bayram e confermato nel bollettino ufficiale di WordPress 7.1.4. Il relativo advisory del progetto WordPress individua le versioni vulnerabili e i rilasci correttivi, senza assegnare un identificativo CVE. Wordfence attribuisce alla falla un punteggio CVSS 8,1, mentre l’advisory GitHub la classifica con gravità bassa in considerazione della particolare difficoltà di sfruttamento. Le due valutazioni riflettono criteri di rischio differenti: l’impatto potenziale è elevato, ma la riuscita richiede condizioni operative molto specifiche.

Wordfence registra 62.969 attacchi e scansioni prolungate per ore

La disponibilità della patch non ha impedito agli operatori malevoli di tentare immediatamente lo sfruttamento della debolezza. Secondo i dati Wordfence, sono stati bloccati 62.969 tentativi di attacco nell’arco di 24 ore, con un’attività caratterizzata dalla ricerca continua di directory temporanee e file appartenenti al processo d’installazione. La società di sicurezza aveva già rilevato oltre 18.500 richieste nelle prime 21 ore successive alla distribuzione della regola firewall, introdotta il 28 ottobre alle 20:30 UTC. La prima richiesta corrispondente alla nuova firma è stata osservata nove minuti dopo l’attivazione della protezione. Particolarmente significativo è il comportamento di due sorgenti che avrebbero interrogato ripetutamente gruppi limitati di siti per circa 14 ore e mezza, una strategia coerente con il tentativo di intercettare l’istante nel quale WordPress espone temporaneamente i file vulnerabili. Altri sistemi hanno invece sperimentato diverse combinazioni di directory e versioni. Questi dati dimostrano la presenza di tentativi automatizzati di sfruttamento, ma non permettono di stabilire quante installazioni abbiano effettivamente subito un’esecuzione di codice. Non risultano documentate, nelle fonti consultate, compromissioni confermate attribuite specificamente alla vulnerabilità.

Leggi anche: WordPress 7.1.2 corregge CVE-2026-87902: path traversal pre-auth fino alla RCE

La falla riguarda il core e non richiede plugin vulnerabili

L’aspetto più delicato della scoperta riguarda la superficie d’attacco. La vulnerabilità si trova nel meccanismo di aggiornamento del software principale, coinvolgendo potenzialmente installazioni WordPress molto differenti fra loro per tema, plugin, hosting e configurazione applicativa. Le versioni interessate comprendono i rami dalla 4.7 fino alla 7.1.3, ma la presenza di una versione vulnerabile non significa che il sito possa essere compromesso in qualsiasi momento. L’attaccante deve individuare un aggiornamento completo in corso, raggiungere i file temporanei, disporre di un server che ne consenta l’esecuzione PHP e completare l’interazione prima della rimozione della directory. La finestra è stata osservata per pochi secondi negli ambienti di prova, circostanza che spiega l’impiego di scansioni continue anziché di singoli tentativi. La situazione si distingue dalle precedenti vulnerabilità del core, come Click2Shell e i problemi di gestione delle funzioni amministrative, perché il vettore non nasce da una normale funzionalità editoriale ma da una fase transitoria della manutenzione. Per le installazioni ospitate su infrastrutture condivise, la corretta segregazione delle directory e l’esecuzione controllata di PHP rappresentano misure di difesa aggiuntive, senza sostituire gli aggiornamenti di sicurezza.

WordPress 7.1.4 corregge il problema e protegge anche i vecchi rami

La risposta degli sviluppatori è arrivata il 28 ottobre 2026, con una release che modifica il comportamento dell’aggiornamento per ridurre la prevedibilità dei percorsi temporanei e impedire l’esposizione impropria dei file utilizzati durante l’installazione. Le correzioni comprendono la generazione di directory di staging meno prevedibili, protezioni contro l’accesso indesiderato e modifiche alla gestione dei file di configurazione. La versione principale raccomandata è WordPress 7.1.4, mentre per chi non può migrare immediatamente all’ultima generazione sono stati predisposti aggiornamenti correttivi per i rami precedenti, fra cui 7.0.8, 6.9.11 e 6.8.12, fino a 4.7.39. La disponibilità delle backport non equivale però al supporto completo delle vecchie versioni: WordPress ricorda che soltanto l’ultima release riceve supporto attivo generale. Gli amministratori devono quindi verificare che il CMS abbia effettivamente completato l’installazione dell’aggiornamento, anziché presumere che i meccanismi automatici abbiano funzionato correttamente. Il controllo diventa particolarmente importante nei siti dove aggiornamenti e cron job sono gestiti tramite procedure personalizzate, hosting amministrati o finestre di manutenzione programmate.

Firewall, log e controlli dopo l’aggiornamento

L’installazione della versione correttiva rimane l’intervento prioritario, ma per i siti che hanno attraversato la finestra di esposizione è opportuno effettuare controlli supplementari. Gli amministratori dovrebbero esaminare le richieste HTTP indirizzate a file PHP nella directory wp-content/upgrade, soprattutto quelle associate a percorsi di installazione temporanei durante gli aggiornamenti del core. La presenza di queste richieste rappresenta un indicatore di probing, non una prova sufficiente di compromissione. Occorre inoltre verificare eventuali account amministrativi inattesi, file PHP sconosciuti, plugin aggiunti senza autorizzazione e modifiche non giustificate ai componenti principali del CMS. Wordfence ha distribuito una regola dedicata ai clienti Premium, Care e Response dal 28 ottobre, programmando la disponibilità per gli utenti Free al 27 novembre 2026. La protezione anticipata del traffico tramite firewall può ridurre la superficie d’attacco, ma non elimina il difetto nelle installazioni non aggiornate. Questo episodio dimostra soprattutto che la sicurezza del ciclo di aggiornamento è importante quanto quella del software in esecuzione: una procedura progettata per correggere vulnerabilità può diventare essa stessa un bersaglio se espone temporaneamente componenti eseguibili e prevedibili. Per editori, aziende e amministrazioni italiane che utilizzano WordPress, il controllo della versione installata e dei log durante gli aggiornamenti è quindi una misura concreta e immediata.