WordPress 7.1.3 corregge XSS nei commenti e falle sui post privati
WordPress 7.1.3 è stato rilasciato il 6 ottobre 2026 come versione di manutenzione e sicurezza con sette correzioni di sicurezza e quattro correzioni di bug. Segue WordPress 7.1.2, che due settimane prima aveva corretto una singola vulnerabilità tracciata come CVE-2026-87902 che consentiva a un visitatore non autenticato di innescare un'inclusione di file locale e, con la giusta configurazione PHP, poteva portare all'esecuzione di codice remoto. Questa versione è di tipo diverso: due delle correzioni partono da un visitatore non autenticato, la perdita dal feed dei commenti e l'XSS nei commenti, che richiede anche il clic di un moderatore. Tre richiedono un account Contributor o Author, una richiede che un amministratore esegua un'esportazione e una è un rafforzamento dipendente dai plugin. Patchstack, la società di sicurezza che ha pubblicato l'analisi, definisce l'aggiornamento urgente ma non un'emergenza assoluta.
La correzione più eclatante è una vulnerabilità di cross-site scripting (XSS) memorizzato nella pagina di amministrazione dei commenti di WordPress. L'XSS consente a un utente malintenzionato di inserire codice dannoso in una pagina che altre persone visualizzeranno in seguito. Il gestore del clic sulla scheda Aiuto in `wp-admin/js/common.js` passava l'href di un link a `$()` di jQuery, che costruisce HTML da qualsiasi stringa che assomigli a HTML. Un link all'interno di un commento in attesa può contenere un href di questo tipo. Il gestore ascolta solo all'interno di elementi con la classe `contextual-help-tabs`, quindi il link necessita anche di un contenitore con quella classe. Prima di WordPress 7.1.0, i commenti dei visitatori non potevano contenere una classe; la 7.1.0 ha aggiunto il supporto per la classe span per le menzioni delle note e la riduce al salvataggio. Secondo l'analisi di Patchstack, l'attacco tramite commento in attesa colpisce le versioni dalla 7.1.0 alla 7.1.2, e i backport più vecchi rafforzano lo stesso codice. La correzione nella 7.1.3 sostituisce il comportamento con `.find()`, che legge solo i selettori. La vulnerabilità è stata segnalata da Thomas Chauchefoin di Trail of Bits.
Due problemi distinti riguardano la divulgazione di informazioni. Per i feed dei commenti dei singoli post, `WP_Query` caricava i commenti di un post prima di verificare se un visitatore potesse vedere il post. Il controllo di visibilità poi cancellava il post ma non i commenti, e poiché i feed non restituiscono mai uno stato 404, il feed stampava i commenti di post privati o non pubblicati a chiunque. La correzione sposta la query dei commenti dopo il controllo di visibilità; questo è stato segnalato da Ananda Dhakal di Patchstack. Nel caso di Imgur, WordPress normalmente filtra l'HTML proveniente da provider oEmbed non attendibili riducendolo a un iframe sandbox. Imgur, tuttavia, era nella lista dei provider attendibili, il che salta quel filtro, quindi qualsiasi cosa provenisse dall'API di Imgur veniva emessa direttamente. Quella risposta include testo dall'immagine o dall'album del caricatore, quindi qualsiasi cosa controllata dall'attaccante finiva sulla pagina non filtrata. La correzione rimuove Imgur come provider attendibile, quindi gli URL di Imgur non vengono più incorporati senza filtro. In particolare, l'aggiornamento non rimuove il contenuto oEmbed memorizzato nella cache esistente in `_oembed_*` post meta e nei post `oembed_cache`, quindi un incorporamento dannoso esistente continua a essere visualizzato finché la cache del sito non viene svuotata. Questo problema è stato segnalato da Zhengyu Liu, Jingcheng Yang e Gavin Zhong.
Diverse altre correzioni richiedono un account Contributor o superiore. Un denial of service in `WP_Http::make_absolute_url()` derivava da un ciclo che comprime le coppie segmento/../ ma non esce mai su un percorso relativo come `a//../b`, perché la sua regex non corrisponde a nulla e il percorso non cambia mai. Un Contributor può attivarlo tramite l'anteprima dei link nell'editor a blocchi puntandolo a una pagina che controlla; la 7.1.3 interrompe il ciclo quando un passaggio non sostituisce nulla. Un'iniezione SQL di secondo ordine nell'esportazione WXR raccoglieva gli ID delle immagini in evidenza direttamente dai metadati `_thumbnail_id` e li concatenava in una stringa di query senza garantire che l'ID fosse un intero. La correzione aggiunge `absint()` in tre punti. Il codice vulnerabile esiste solo da WordPress 6.5.0 e viene raggiunto solo quando si esporta un singolo tipo di contenuto; l'esportazione predefinita "Tutto il contenuto" non lo tocca. Gli autori potevano anche contrassegnare i post come in evidenza perché l'API REST rifiutava una richiesta di post in evidenza solo quando l'utente mancava sia delle capacità `edit_others_posts` che `publish_posts`. Gli autori hanno la capacità `publish_posts`, quindi passavano; la correzione cambia `&&` (e) in `||` (o). Sia il denial of service che l'iniezione SQL sono stati segnalati da Anthropic.
L'ultima correzione riguarda una collisione di nomi di hook. WordPress costruisce alcuni nomi di azione dai dati del post stesso. Quando un post cambia stato, `wp_transition_post_status()` attiva `${new_status}_{$post_type}`, quindi pubblicare un post attiva `publish_post`. Azioni non correlate seguono lo stesso schema di denominazione: `delete_post` si attiva quando un post viene eliminato, e `comment_post` si attiva quando viene aggiunto un commento. Prima della 7.1.2, WordPress non verificava mai che lo stato e il tipo di post fossero registrati prima di costruire il nome. Un post salvato con lo stato `delete` e il tipo `post` avrebbe attivato `delete_post`, la stessa azione di un'eliminazione reale, e ogni callback agganciato a essa sarebbe stato eseguito come se un post fosse appena stato eliminato. La correzione attiva questi hook solo quando lo stato e il tipo di post sono registrati. Questo è stato segnalato da Alex Concha del WordPress Security Team.
WordPress 7.1.3 è disponibile dalla Bacheca sotto Aggiornamenti o da WordPress.org, e i siti con aggiornamenti automatici in background lo riceveranno da soli. Le correzioni sono state backportate ai rami più vecchi almeno fino alle versioni 6.6, ma al momento della pubblicazione di Patchstack, i rami dalla 4.7 alla 6.5 dovevano ancora essere patchati. Patchstack ha anche aggiunto le vulnerabilità pubblicate al suo database lo stesso giorno. Durante l'aggiornamento, i proprietari dei siti dovrebbero verificare chi detiene ruoli Contributor o superiori, perché molte di queste correzioni riguardano ciò che quei ruoli possono raggiungere. Per i proprietari di siti su hosting WordPress gestito come AEU Hosting, gli aggiornamenti automatici del core, gli ambienti di staging e il rafforzamento della sicurezza rendono più facile applicare una versione come la 7.1.3, svuotare le cache dopo l'applicazione della patch e rivedere quali account detengono ruoli Contributor o superiori prima che un commento in attesa raggiunga un moderatore.