WordPress 7.1.4 corregge una RCE nel Core durante attività di probing da parte degli aggressori
WordPress 7.1.4 è stato rilasciato il 28 ottobre 2026 con correzioni per 22 vulnerabilità di sicurezza, tra cui una vulnerabilità di remote code execution (RCE) senza autenticazione, che potrebbe consentire a un aggressore di eseguire codice su un server senza prima effettuare l'accesso. Wordfence riferisce che gli aggressori hanno iniziato a effettuare probing della vulnerabilità poco dopo il rilascio dell'aggiornamento di sicurezza. I proprietari dei siti dovrebbero verificare che WordPress abbia installato la versione 7.1.4 o il corrispondente aggiornamento di sicurezza per il loro branch precedente, anziché presumere che l'aggiornamento automatico sia riuscito.
Il problema più grave interessa le versioni di WordPress Core dalla 4.7 alla 7.1.3 e ha un punteggio CVSS di 8.1, classificato High. CVSS, o Common Vulnerability Scoring System, è una scala standard utilizzata per descrivere la gravità di una vulnerabilità di sicurezza. La vulnerabilità è una race condition, il che significa che un aggressore deve agire durante un breve periodo in cui due processi si sovrappongono. Non è necessario alcun account sul sito, ma l'aggressore deve intercettare WordPress mentre decomprime un aggiornamento completo del Core.
Durante questo tipo di aggiornamento, le versioni vulnerabili estraggono i nuovi file di WordPress in una directory prevedibile all'interno di wp-content/upgrade. Questa staging directory, una posizione temporanea utilizzata prima che i nuovi file diventino attivi, include il programma di installazione di WordPress. Su molti server è accessibile dal web pubblico. Un aggressore che individua o prevede il percorso può richiedere ripetutamente il file temporaneo setup-config.php e interagire con l'installazione temporanea prima che WordPress la rimuova. PHP è il linguaggio di programmazione server-side utilizzato per eseguire WordPress e l'accesso a questo file PHP temporaneo può infine consentire l'esecuzione di codice sull'host.
Devono verificarsi contemporaneamente diverse condizioni. WordPress deve elaborare un pacchetto completo contenente i file del programma di installazione, la directory temporanea deve consentire l'accesso dal web pubblico e tramite PHP, il percorso deve essere prevedibile o scoperto e l'aggressore deve completare l'operazione prima della pulizia. Wordfence afferma che i test di laboratorio hanno rilevato che la directory vulnerabile rimaneva generalmente disponibile solo per pochi secondi. È quindi improbabile che una singola richiesta riesca, ma il polling automatizzato può verificare ripetutamente un sito nel tentativo di intercettare l'apertura.
WordPress 7.1.4 modifica questo processo rendendo casuale la staging directory, inserendovi un index guard e bloccando la promozione non sicura dei dati di configurazione temporanei. Le correzioni sono state anche sottoposte a backport fino a WordPress 4.7. Le versioni 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 le versioni precedenti non ricevono più aggiornamenti di sicurezza e devono essere trasferiti a una release supportata.
Il probing attivo è iniziato rapidamente. Wordfence ha distribuito una nuova regola del firewall alle 20:30 UTC del 28 ottobre, circa tre ore dopo il rilascio dell'aggiornamento di sicurezza di WordPress. Un firewall filtra le richieste potenzialmente dannose prima che raggiungano un sito. 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.
Wordfence ha registrato il primo riscontro per questa regola nove minuti dopo il deployment. Nelle prime 21 ore, la telemetry dell'azienda, ossia i dati sugli eventi di sicurezza raccolti dai siti protetti, ha rilevato più di 18.500 richieste dirette a percorsi temporanei di setup-config.php. Due delle principali origini hanno sottoposto ripetutamente a polling piccoli gruppi di siti per circa 14,5 ore. Altre origini hanno provato numerose combinazioni di staging directory e nomi di versione. Wordfence osserva che non tutte le richieste utilizzavano il percorso vulnerabile preciso, ma afferma che il polling prolungato e la struttura esatta delle directory dimostrano che gli aggressori avevano compreso la vulnerabilità temporale e avevano iniziato a prenderla di mira. Il rapporto non afferma che ogni tentativo di probing abbia avuto successo.
La regola del firewall presenta un importante requisito di deployment. La richiesta dannosa raggiunge direttamente un file PHP temporaneo senza prima caricare WordPress. I siti che utilizzano Wordfence necessitano quindi della modalità Extended Protection, che avvia il firewall prima che le richieste PHP dirette raggiungano il file richiesto. Una regola del firewall può ridurre l'esposizione, ma non elimina il comportamento vulnerabile del Core e non sostituisce l'installazione di una versione corretta.
Le altre correzioni incluse in WordPress 7.1.4 riguardano diverse categorie di sicurezza. Molteplici vulnerabilità di stored cross-site scripting (XSS), nelle quali codice dannoso per il browser viene salvato su un sito e successivamente mostrato a un altro utente, interessavano i delimitatori dei block, il Categories block, le etichette di Comments Pagination e Post Navigation, il Customizer selective refresh, le richieste di cancellazione dei dati personali, nomi utente appositamente costruiti e l'elaborazione degli Image e Playlist block. Alcune richiedono un account Contributor, Author o Editor e diverse dipendono anche dal fatto che un utente con privilegi maggiori visualizzi contenuti controllati dall'aggressore. Questi requisiti limitano l'esposizione rispetto alla RCE senza autenticazione, ma lo stored XSS può comunque causare l'acquisizione di account o modifiche non autorizzate al sito.
La release corregge inoltre problemi dell'Interactivity API relativi a URL, event handler, proprietà interne e object binding non sicuri. Un'API è una modalità definita con cui i componenti software si scambiano istruzioni o dati. Ulteriori correzioni riguardano la prototype pollution, in cui un input modifica proprietà ereditate da altri oggetti software, il data shadowing degli Script Module, l'elaborazione dei file di testo caricati nell'Interactivity Router e una condizione persistente di denial of service, che può mantenere indisponibile un servizio esaurendone o bloccandone le risorse.
Altre patch risolvono la divulgazione senza autenticazione di changeset del Customizer non pubblicati e una debolezza di autorizzazione nella Notes REST API. Questo problema relativo ai permessi interessava i ruoli personalizzati autorizzati a moderare i commenti ma non a modificare il post contenente una nota. Anche i root certificate inclusi, che aiutano il software a decidere quali connessioni cifrate considerare attendibili, sono stati aggiornati in seguito alla revoca di eMudhra.
I proprietari i cui siti sono rimasti senza patch dovrebbero esaminare le richieste ai file PHP all'interno di wp-content/upgrade e verificare la presenza di account amministratore sconosciuti, plugin inattesi o file PHP che non hanno aggiunto. Wordfence consiglia inoltre di eseguire una scansione dopo l'aggiornamento per individuare file del Core modificati, file dannosi o altre prove che richiedano ulteriori indagini. Per i proprietari di siti che stanno valutando a chi spetti la responsabilità della sicurezza di WordPress, AEU Hosting offre managed WordPress hosting protetto end to end.
La priorità immediata è aprire Bacheca > Aggiornamenti e verificare la release installata. Gli aggiornamenti automatici in background dovrebbero distribuire la correzione alla maggior parte dei siti, ma un aggiornamento non riuscito o ritardato lascerebbe attivo il comportamento vulnerabile dell'upgrade. Verificare la versione, controllare eventuali attività sospette e indagare sulle modifiche inattese è necessario perché gli aggressori stanno già tentando attivamente di intercettare la breve finestra temporale dell'aggiornamento.