WordPress 7.1.4 corregge una RCE mentre gli attaccanti sondano i siti
WordPress 7.1.4, pubblicato il 28 ottobre 2026, corregge 22 vulnerabilità di sicurezza, tra cui una vulnerabilità di remote code execution che potrebbe consentire a un attaccante di eseguire codice sul server di un sito web senza disporre di un account. Wordfence riferisce che gli attaccanti hanno iniziato a effettuare probing della vulnerabilità pochi minuti dopo il deployment di una nuova regola del firewall, rendendo importante per i proprietari dei siti verificare che la propria installazione abbia effettivamente ricevuto l'aggiornamento di sicurezza.
Il problema più grave è CVE-2026-119977, valutato 8,1, ovvero High, secondo il Common Vulnerability Scoring System (CVSS), una scala standard per valutare le vulnerabilità di sicurezza. Interessa WordPress Core, il software principale su cui si basa un sito WordPress, dalla versione 4.7 alla 7.1.3. La vulnerabilità è una race condition non autenticata: un attaccante privo di account deve agire durante una sequenza di eventi molto breve e con tempistiche estremamente precise. Lo sfruttamento riuscito può causare una remote code execution (RCE), che consente di eseguire codice sul server da remoto.
Il momento vulnerabile si verifica durante un aggiornamento di WordPress Core che utilizza un package WordPress completo. Le versioni interessate estraggono i file sostitutivi in una directory temporanea prevedibile all'interno di wp-content/upgrade. Questa copia in staging, cioè composta da file preparati temporaneamente prima di essere messi in uso, include l'installer di WordPress. Sui server in cui tale directory temporanea è raggiungibile dal web, un attaccante può richiedere l'installer mentre l'aggiornamento è in corso, interagire con la copia di WordPress in staging e procedere verso l'esecuzione di PHP, il linguaggio di programmazione utilizzato per eseguire WordPress.
Devono coincidere diverse condizioni. L'aggiornamento deve utilizzare un package completo contenente l'installer, la staging directory deve consentire l'accesso pubblico tramite web e PHP, l'attaccante deve prevederne o scoprirne il percorso e il processo deve rimanere disponibile abbastanza a lungo da completare l'attacco prima che WordPress elimini i file temporanei. Le osservazioni di laboratorio citate da Wordfence hanno rilevato che la directory esposta normalmente esisteva soltanto per pochi secondi. È quindi improbabile che una singola richiesta arrivi nel momento corretto, ma richieste automatizzate ripetute possono aumentare la probabilità di vincere la race condition.
WordPress 7.1.4 modifica questo processo rendendo casuale la directory temporanea, inserendovi un file index protettivo e bloccando la promozione non sicura dei dati di configurazione in staging. La correzione è stata inoltre sottoposta a backport fino a branch risalenti a WordPress 4.7. Le release corrette sono 4.7.39, 4.8.34, 4.9.35, 5.0.31, 5.1.28, 5.2.30, 5.3.27, 5.4.25, 5.5.24, 5.6.23, 5.7.21, 5.8.19, 5.9.20, 6.0.18, 6.1.16, 6.2.15, 6.3.14, 6.4.14, 6.5.14, 6.6.11, 6.7.11, 6.8.12, 6.9.11, 7.0.8 e 7.1.4. WordPress 4.6 e versioni precedenti non ricevono più aggiornamenti di sicurezza e devono essere migrate a una release supportata.
Wordfence afferma di aver effettuato il deployment di una regola del firewall alle 20:30 UTC del 28 ottobre, circa tre ore dopo l'annuncio della release da parte di WordPress. Un firewall è un software che esamina le richieste e blocca il traffico corrispondente a pattern dannosi. I clienti Wordfence Premium, Care e Response hanno ricevuto immediatamente la regola, mentre gli utenti di Wordfence Free dovrebbero riceverla il 27 novembre 2026, dopo il ritardo standard di 30 giorni. Il primo match è apparso nove minuti dopo il deployment. Nelle 21 ore successive, Wordfence ha registrato oltre 18.500 richieste dirette a percorsi dell'installer setup-config.php in staging.
Due delle principali fonti di richieste hanno controllato ripetutamente piccoli gruppi di siti per circa 14,5 ore, un comportamento che secondo Wordfence era compatibile con tentativi di intercettare la breve finestra di aggiornamento. Altre fonti hanno provato numerose varianti dei nomi della staging directory e delle versioni. Non tutte le richieste corrispondevano esattamente al percorso vulnerabile, ma il polling continuo e i probe basati sulla struttura prevista della directory hanno mostrato che gli attaccanti avevano iniziato a prendere di mira la vulnerabilità legata alle tempistiche.
I siti che utilizzano Wordfence necessitano della modalità Extended Protection affinché questa specifica regola possa intervenire abbastanza presto. L'exploit richiede direttamente un file PHP in staging invece di caricare prima WordPress, quindi il firewall deve essere eseguito prima che venga raggiunto il file richiesto. Wordfence sottolinea che questa regola non sostituisce l'aggiornamento, perché l'installazione di una release corretta di WordPress Core elimina direttamente il comportamento vulnerabile.
Le altre correzioni riguardano diverse categorie di sicurezza. WordPress elenca problemi di stored cross-site scripting, nei quali codice dannoso per il browser viene salvato su un sito e viene eseguito in seguito quando qualcuno visualizza il contenuto interessato, relativi ai delimitatori dei block, al block Categories, alle etichette Comments Pagination e Post Navigation, al selective refresh di Customizer, alle richieste di cancellazione dei dati personali, a username appositamente costruiti e alla gestione dei block Image e Playlist.
La release risolve anche problemi dell'Interactivity API relativi a binding non sicuri di URL, event-handler, proprietà interne e oggetti. L'Interactivity API è un'interfaccia di WordPress utilizzata per aggiungere comportamenti interattivi alle pagine. Le correzioni correlate riguardano la prototype pollution, che consente ai dati di modificare proprietà ereditate da altri oggetti software, il data shadowing di Script Module, la gestione dei file di testo caricati nell'Interactivity Router e una condizione persistente di denial of service che potrebbe impedire a un servizio di funzionare normalmente.
Ulteriori correzioni risolvono la divulgazione non autenticata di changeset non pubblicati di Customizer e una debolezza di autorizzazione nella Notes REST API. Una REST API è un'interfaccia attraverso la quale un software invia richieste web a un'altra applicazione. La vulnerabilità di Notes interessa i ruoli personalizzati autorizzati a moderare i commenti ma non a modificare il post contenente una nota. WordPress ha inoltre aggiornato i root certificates inclusi, record attendibili utilizzati per verificare le connessioni sicure, in seguito alla revoca di eMudhra.
Molte di queste vulnerabilità aggiuntive richiedono un account Contributor, Author o Editor autenticato e alcune richiedono anche che una vittima apra contenuti controllati dall'attaccante. Questi requisiti limitano l'esposizione rispetto alla RCE non autenticata, ma lo stored cross-site scripting può comunque consentire l'acquisizione di account o modifiche non autorizzate del sito quando un utente con privilegi visualizza una pagina dannosa.
I proprietari dei siti devono aprire Dashboard, selezionare Updates e verificare che la versione visualizzata sia la 7.1.4 o la release corretta per il proprio branch, anziché presumere che l'aggiornamento automatico in background sia riuscito. Se un sito è rimasto privo della correzione, gli amministratori devono esaminare le richieste a file PHP all'interno di wp-content/upgrade e indagare su account amministratore sconosciuti, plugin inattesi o file PHP che non hanno installato. Wordfence consiglia inoltre di eseguire la propria scansione dopo l'aggiornamento per cercare file di WordPress Core alterati, file dannosi e altre prove che richiedano ulteriori indagini.
Per le organizzazioni che preferiscono un ambiente gestito, AEU Hosting offre hosting WordPress gestito e protetto end-to-end. Indipendentemente dalla soluzione di hosting, la risposta essenziale consiste nell'installare la release di sicurezza appropriata e verificare che l'aggiornamento sia stato completato, perché gli attaccanti stanno già effettuando ripetutamente probing alla ricerca del breve momento di vulnerabilità.