WordPress 7.1.1 corregge una XSS non autenticata in wpautop()

WordPress 7.1.1, rilasciato il 17 settembre 2026, corregge 11 vulnerabilità di sicurezza e 17 bug in WordPress Core, e la più grave di esse consente a un visitatore anonimo di inserire codice su un sito che accetta commenti pubblici. La vulnerabilità è una cross-site scripting (XSS) memorizzata non autenticata in wpautop(), la funzione che trasforma le interruzioni di riga in paragrafi su quasi ogni contenuto che WordPress visualizza. Una vulnerabilità XSS è una vulnerabilità in cui un attaccante riesce a far eseguire il proprio codice all'interno del browser di chi visita un sito, come se fosse stato il sito stesso a servirlo, e la parola memorizzata significa che il contenuto malevolo viene prima salvato sul sito e poi consegnato a ogni visitatore che carica la pagina interessata. La vulnerabilità interessa WordPress Core fino alla versione 7.1 inclusa e ha l'identificatore CVE-2026-93485. È stata segnalata da Rafie Muhammad ed è descritta in un'analisi di Patchstack, che afferma che i clienti dell'azienda sono protetti e che raccomanda comunque di aggiornare alla versione più recente di WordPress disponibile. La voce ha anche un punteggio CVSS 3.1 di 7.1, secondo il vettore AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L. CVSS è una scala di gravità ampiamente utilizzata in cui un numero più alto indica una vulnerabilità più grave.

Il punto di ingresso è ciò che rende questo caso insolito. L'analisi di Patchstack osserva che l'attacco non richiede alcun account. Il payload viene inserito in un normale commento e inviato tramite il normale modulo di commento da un visitatore anonimo. Supera wp_kses(), il componente di WordPress che ripulisce i commenti da markup pericoloso, perché nulla nel testo inviato assomiglia al tipo di markup che wp_kses() esiste per rimuovere. Una volta memorizzato, il commento appare innocuo. Diventa pericoloso solo in seguito, quando il sito lo visualizza e i filtri di visualizzazione riorganizzano ciò che è presente.

Il punto di sbocco è wpautop() in wp-includes/formatting.php. Patchstack lo descrive come l'unico filtro di contenuto in WordPress Core che non analizza l'HTML: lavora su testo grezzo usando espressioni regolari, che sono schemi di ricerca e sostituzione, e una di queste espressioni non era a conoscenza dei valori degli attributi tra virgolette. Il pattern usato nelle versioni fino alla 7.1 inclusa catturava tutto ciò che si trovava tra un tag di paragrafo e il primo carattere > incontrato. Questo si comporta correttamente per un tag ben formato, dove il primo > è quello che lo chiude. Si rompe quando un > compare all'interno di un valore di attributo tra virgolette, perché l'espressione legge allora la parte centrale di un attributo come fine del tag e vi sposta un elemento paragrafo.

L'attaccante non deve fornire quel carattere >. Poche righe prima nella stessa funzione, wpautop() protegge le interruzioni di riga che si trovano all'interno dei tag sostituendole con un segnaposto, e quel segnaposto è un commento HTML. Un commento HTML termina con -->, quindi una semplice interruzione di riga all'interno di un valore di attributo diventa un > che si trova all'interno di un valore di attributo. La lista bianca dei commenti di WordPress permette , e un'interruzione di riga all'interno di quel valore cite non è qualcosa che wp_kses() abbia motivo di rimuovere. Come dice Patchstack, WordPress fornisce il carattere necessario all'attacco.

Da lì il tag viene spezzato a metà, la vera virgoletta di chiusura dell'attributo rimane isolata, e i restanti filtri di visualizzazione completano il lavoro. Il testo controllato dall'attaccante finisce nella parte del tag dove dovrebbero stare gli attributi, anziché al sicuro all'interno di un valore di attributo, quindi il risultato è l'esecuzione di script nell'origine del sito stesso per qualsiasi visitatore che carica la pagina, che sia connesso o meno. Patchstack afferma che non pubblicherà la catena di breakout né un payload funzionante. La correzione in WordPress 7.1.1 rende l'espressione consapevole delle virgolette, così un > all'interno di un valore tra virgolette non viene più letto come fine di un tag.

Una cosa impedisce che la vulnerabilità sia un attacco drive-by. Patchstack osserva che il commento deve essere pubblicato. Su un'installazione WordPress standard, un'impostazione chiamata comment_previously_approved trattiene il commento di chi commenta per la prima volta per la moderazione, quindi il payload resta in coda finché un moderatore non lo approva. Questo rallenta un attaccante, ma la moderazione non è un controllo di sicurezza. Approvare commenti è un lavoro di routine, il payload non sembra degno di nota nella coda di moderazione, e chi ha già avuto un commento approvato in passato viene approvato automaticamente da quel momento in poi. I siti che accettano commenti pubblici dovrebbero considerare questa come la correzione prioritaria del rilascio, specialmente dove la moderazione è delegata o dove i commentatori di ritorno vengono approvati automaticamente.

La cronologia della divulgazione, come la registra Patchstack, inizia il 15 settembre 2026, quando Rafie Muhammad ha segnalato il problema al Patchstack Vulnerability Disclosure Program, dove è stato convalidato e confermato essere stato comunicato al team di WordPress. WordPress 7.1.1 è stato rilasciato con la correzione il 17 settembre 2026, insieme ai backport per i rami più vecchi ancora supportati. La voce è stata pubblicata nel database delle vulnerabilità di Patchstack il 18 settembre 2026.

Le altre dieci correzioni sono per lo più problemi di controllo degli accessi e di divulgazione, e la maggior parte di esse richiede un account con determinati privilegi sul sito. Un accesso di livello Contributor è bastato per una sovrascrittura arbitraria di post e per un path traversal nel controller dei template della REST API, entrambi segnalati da Anthropic. Un path traversal è una vulnerabilità che consente di raggiungere file al di fuori della cartella a cui si dovrebbe essere limitati, e la REST API è l'interfaccia standard che WordPress espone affinché altri software possano leggere e modificare i contenuti. Un accesso di livello Contributor è bastato anche per divulgare gli slug, i brevi nomi identificativi, dei post in bozza e in attesa, segnalato da hermanhms. Qualsiasi utente autenticato poteva riassegnare il genitore dei commenti, incluse le note, segnalato da viridis. Un accesso di livello Author è bastato per pubblicare post changeset tramite XML-RPC, una vecchia interfaccia remota per software esterni, in un modo che aggirava il controllo delle capacità per il CSS personalizzato, segnalato da Ben Bidner del WordPress Security Team. Il resto sono una XSS memorizzata nelle immagini di intestazione personalizzate su alcuni temi e un problema dell'API HTML che permetteva a testo modificato di uscire da un commento HTML, entrambi segnalati da Jeremy Felt del WordPress Security Team; un URL creato ad arte che poteva installare e visualizzare in anteprima un tema da WordPress.org, segnalato da Paulos Yibelo e pwn.ai; un problema Multisite che permetteva a un amministratore di sito di attivare a livello di rete un plugin destinato a essere disponibile solo su tutta una rete, segnalato da Jesse McNeil; e una divulgazione di informazioni che esponeva il titolo di un post genitore privato, segnalato da HDWSec. Multisite è una funzionalità di WordPress che gestisce diversi siti web da un'unica installazione, e attivare un plugin a livello di rete significa accenderlo per ogni sito di quella rete contemporaneamente.

WordPress 7.1.1 è disponibile dalla Dashboard sotto Aggiornamenti, o direttamente da WordPress.org, e i siti con gli aggiornamenti automatici in background abilitati lo riceveranno da soli. Il team di WordPress ha portato queste correzioni ai rami più vecchi fino alla versione 4.7; un backport è una correzione scritta per la versione più recente che viene poi applicata a una versione più vecchia ancora supportata. Le note di rilascio indicano quale ramo ha ricevuto quale correzione, ma il consiglio di Patchstack è netto: solo la versione più recente di WordPress è attivamente supportata, ed è quella su cui bisogna stare. Per i proprietari di siti che preferiscono non seguire a mano ogni rilascio del core, AEU Hosting offre hosting WordPress gestito con la sicurezza gestita end to end, e la sua pagina di servizio spiega cosa comprende.