WordPress 7.1.3 corregge sette vulnerabilità di sicurezza
WordPress 7.1.3 corregge sette vulnerabilità di sicurezza e quattro bug software in una release di manutenzione e sicurezza pubblicata il 6 ottobre 2026. Le falle includono commenti esposti su contenuti privati, due percorsi di cross-site scripting (XSS), un denial of service, un problema di SQL injection legato all'esportazione, autorizzazioni errate per gli sticky posts e una collisione tra nomi di azioni interne. La release merita di essere installata tempestivamente, anche se l'accesso e l'interazione necessari per la maggior parte degli attacchi fanno sì che non venga descritta come un'emergenza immediata per cui interrompere ogni altra attività.
Questa release è diversa da WordPress 7.1.2, pubblicato due settimane prima. Quell'aggiornamento correggeva CVE-2026-87902, un problema che consentiva a un visitatore non autenticato, cioè una persona senza account, di attivare una local file inclusion e potenzialmente indurre il server a caricare un file locale non previsto. Con la configurazione PHP adatta, poteva portare alla remote code execution, cioè all'esecuzione da remoto di comandi sul server. In 7.1.3, due vulnerabilità partono da un visitatore non autenticato, tre richiedono un account Contributor o Author, una richiede che un administrator esegua un'esportazione e una dipende dal modo in cui un plugin fornisce i dati dei post.
Uno dei percorsi senza autenticazione è uno stored cross-site scripting (XSS), nel quale codice ostile per browser viene salvato da un sito e successivamente trasmesso a un altro utente. L'handler della scheda Help in wp-admin/js/common.js passava il valore href di un link alla funzione $() di jQuery, che può costruire HTML quando una stringa assomiglia a codice HTML. Un autore dell'attacco poteva inserire un link di questo tipo all'interno di un commento in attesa, racchiuso in un elemento che utilizzava la class contextual-help-tabs. L'attacco richiedeva comunque che un Editor o un altro moderatore facesse clic sul link durante la revisione del commento.
Prima di WordPress 7.1.0, i commenti dei visitatori non potevano contenere la class richiesta. Quella versione ha introdotto il supporto della class span per le menzioni nelle note e ne limitava il valore al momento del salvataggio. La code review di Patchstack colloca quindi la finestra dell'attacco tramite commenti in attesa nelle versioni dalla 7.1.0 alla 7.1.2. WordPress 7.1.3 sostituisce l'operazione rischiosa con .find(), che interpreta il valore fornito soltanto come selector, cioè un modello per individuare un elemento già presente nella pagina. Gli aggiornamenti con backport per le versioni meno recenti mettono in sicurezza lo stesso codice.
Una falla distinta di denial of service interessava WP_Http::make_absolute_url(). Un denial of service rende un sistema non disponibile o incapace di rispondere adeguatamente. La funzione conteneva un loop destinato a ridurre i segmenti di percorso contenenti segment/../, ma un relative path come a//../b faceva sì che la sua regola di corrispondenza non trovasse nulla. Poiché il percorso rimaneva invariato, il loop non terminava mai. Un utente con un account Contributor poteva raggiungere la falla tramite la link preview del block editor, inserendo un link a una pagina sotto il proprio controllo. Il codice corretto interrompe il loop quando un passaggio non esegue alcuna sostituzione.
Anche la funzione di esportazione WXR conteneva un problema di second-order SQL injection. La SQL injection consiste nell'inserimento di dati manipolati in un comando inviato a un database; second-order significa che il valore pericoloso viene prima memorizzato e utilizzato in un secondo momento. WordPress prendeva gli identificatori delle immagini in evidenza direttamente dai metadata _thumbnail_id e li univa in una query del database senza prima verificare che fossero numeri interi. La versione 7.1.3 applica absint(), che converte un valore in un numero intero non negativo, in tre punti. Il codice vulnerabile era presente dalla versione 6.5.0 e viene raggiunto soltanto quando un administrator esporta un singolo tipo di contenuto. L'esportazione predefinita Tutti i contenuti non lo utilizza.
Gli Author potevano inoltre contrassegnare i post come sticky tramite la REST API, un'interfaccia attraverso la quale il software invia richieste a WordPress. Il controllo delle autorizzazioni rifiutava una richiesta soltanto se all'utente mancavano entrambe le capability edit_others_posts e publish_posts. Gli Author dispongono di publish_posts e quindi superavano il controllo. La correzione modifica la condizione logica da &&, che significa e, a ||, che significa o, così l'assenza di una qualsiasi delle autorizzazioni richieste è sufficiente a bloccare la richiesta.
Il secondo problema senza autenticazione esponeva i commenti associati a post privati o non pubblicati. Per il feed dei commenti di un singolo post, WP_Query recuperava i commenti prima di verificare che il visitatore potesse visualizzare il post. WordPress rimuoveva poi il post dal risultato, ma lasciava al loro posto i relativi commenti. Poiché in questa situazione i feed non restituiscono una risposta 404, i commenti venivano mostrati. La versione 7.1.3 esegue la query dei commenti soltanto dopo il controllo della visibilità.
Un'altra falla XSS riguardava gli embed di Imgur. Normalmente WordPress fa passare l'HTML proveniente da provider oEmbed non attendibili attraverso un filter che lo confina in un sandboxed iframe, un frame isolato all'interno della pagina. Imgur era incluso nell'elenco dei provider attendibili, quindi la risposta della sua API aggirava quel filter e veniva visualizzata direttamente. Queste risposte possono contenere testo fornito da chi carica un'immagine o un album, consentendo a contenuti controllati dall'autore dell'attacco di raggiungere una pagina senza essere filtrati. La correzione rimuove Imgur dall'elenco attendibile, quindi i suoi URL non vengono più incorporati senza tale protezione. Lo sfruttamento richiede un account Contributor o superiore e un bersaglio che visualizzi il contenuto interessato.
L'aggiornamento non rimuove il materiale oEmbed di Imgur già presente nella cache. I metadata dei post _oembed_* e i post oembed_cache esistenti possono quindi continuare a mostrare un embed dannoso. Patchstack consiglia di svuotare la cache del sito dopo aver installato la release, affinché questi contenuti memorizzati non continuino a essere renderizzati.
L'ultima modifica di sicurezza impedisce le collisioni tra i nomi degli action hooks. Gli action hooks sono punti dotati di un nome nei quali i plugin possono eseguire il proprio codice. Quando un post cambia status, wp_transition_post_status() costruisce un hook il cui nome deriva dal nuovo status e dal post type, quindi la pubblicazione di un normale post produce publish_post. Altre operazioni di WordPress utilizzano nomi simili, tra cui delete_post per l'eliminazione e comment_post quando viene aggiunto un commento.
WordPress 7.1.2 non verificava che lo status e il post type forniti fossero registrati prima di costruire quel nome. Un plugin che passava raw data a wp_insert_post() poteva salvare un post con status delete e type post, facendo eseguire delete_post anche se non si era verificata alcuna eliminazione reale. Ogni callback collegato a quell'action si sarebbe quindi comportato come se un post fosse stato eliminato. WordPress 7.1.3 attiva questi hooks costruiti dinamicamente soltanto quando sia lo status sia il post type sono registrati.
I riconoscimenti per le sette correzioni elencavano Trail of Bits, Anthropic, Patchstack, il WordPress Security Team e diversi singoli ricercatori. WordPress 7.1.3 e i backport fino alle release 6.6 sono diventati disponibili il 6 ottobre e Patchstack ha aggiunto le vulnerabilità pubblicate al proprio database lo stesso giorno. Al momento della pubblicazione, le branch dalla 4.7 alla 6.5 non avevano ancora ricevuto le patch.
Gli administrator possono installare WordPress 7.1.3 dalla Bacheca, selezionando poi Aggiornamenti, oppure scaricarlo da WordPress.org. I siti che utilizzano aggiornamenti automatici in background dovrebbero riceverlo automaticamente. Gli administrator dovrebbero inoltre verificare chi dispone dei ruoli Contributor, Author, Editor o superiori, perché diverse di queste falle dipendono dall'accesso fornito da tali account.