WordPress 7.1.1 corregge una stored XSS non autenticata
WordPress 7.1.1 è arrivato il 17 settembre 2026 con 11 correzioni di sicurezza e 17 correzioni di bug di Core, guidate da una vulnerabilità stored cross-site scripting non autenticata in wpautop(). Cross-site scripting, o XSS, significa che un aggressore può fare in modo che un sito esegua script indesiderato nel browser di un visitatore. La stored XSS è più grave di un link una tantum perché il contenuto dannoso viene salvato sul sito e può essere eseguito in seguito per altri visitatori.
Patchstack afferma che la vulnerabilità principale interessa WordPress Core fino alla versione 7.1 inclusa ed è stata assegnata a CVE-2026-93485. Ha un punteggio CVSS 3.1 di 7.1 con il vettore AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L. CVSS, il Common Vulnerability Scoring System, è un metodo standard per descrivere la gravità e le condizioni di attacco. In termini semplici, questo problema può essere raggiunto tramite la rete, non richiede un account, ma richiede un’interazione dell’utente, come la visualizzazione della pagina interessata da parte di qualcuno.
Il dettaglio importante per i proprietari dei siti è il punto di ingresso. Patchstack descrive un payload inserito in un normale commento pubblico tramite il consueto modulo dei commenti da un visitatore anonimo. Supera wp_kses(), il sanificatore dei commenti di WordPress che rimuove il markup non consentito, perché il contenuto inviato inizialmente non assomiglia al tipo di HTML che il filtro è progettato per eliminare. Il pericolo compare più tardi, quando WordPress mostra il commento e i suoi filtri di visualizzazione rimodellano il markup.
La funzione vulnerabile è wpautop(), situata in wp-includes/formatting.php. Questo filtro di Core trasforma le interruzioni di riga in paragrafi in gran parte del contenuto renderizzato da WordPress. Patchstack osserva che wpautop() lavora con testo ed espressioni regolari invece di analizzare l’HTML come farebbe un browser. Un’espressione che spostava i tag di paragrafo attorno ai blockquote non era consapevole dei valori di attributo tra virgolette. Trattava il primo carattere maggiore di incontrato come la fine di un tag, anche quando quel carattere compariva all’interno di un valore di attributo tra virgolette.
La spiegazione di Patchstack è sottile ma importante. Un aggressore non doveva fornire direttamente quel carattere maggiore di. In precedenza in wpautop(), WordPress protegge le nuove righe all’interno dei tag sostituendole con un segnaposto. Quel segnaposto è un commento HTML, e un commento HTML termina con una sequenza che include un carattere maggiore di. La allowlist dei commenti di WordPress consente un blockquote con un attributo cite, e una nuova riga all’interno di quel valore cite non è qualcosa che wp_kses() normalmente rimuoverebbe. Il processo di visualizzazione fornisce quindi il carattere che in seguito aiuta a rompere la struttura del tag.
Quando ciò accade, il tag può essere diviso nel punto sbagliato, la vera virgoletta di chiusura dell’attributo viene lasciata fuori posizione e i filtri di visualizzazione successivi completano la trasformazione. Patchstack afferma che il testo controllato dall’aggressore può finire dove dovrebbero trovarsi gli attributi, invece che al sicuro all’interno di un valore di attributo. Il risultato è l’esecuzione di script nell’origine propria del sito per qualsiasi visitatore che carichi la pagina, che quel visitatore abbia effettuato l’accesso oppure no. Patchstack non ha pubblicato un payload funzionante né la catena completa di breakout.
La correzione in WordPress 7.1.1 modifica l’espressione pertinente in modo che comprenda i valori tra virgolette. Ciò significa che un carattere maggiore di all’interno di un attributo tra virgolette non viene più trattato come la fine del tag. Patchstack afferma che i suoi clienti sono protetti da questo problema stored XSS, pur continuando a raccomandare che i siti si aggiornino alla versione di WordPress più recente disponibile.
C’è un limite pratico allo sfruttamento: il commento deve essere pubblicato. In un’installazione WordPress standard, comment_previously_approved trattiene un commentatore alla prima esperienza in moderazione, il che significa che il payload attende in coda finché qualcuno non lo approva. Ma la moderazione non è un confine di sicurezza. Approvare commenti è un’attività di routine, il commento dannoso può sembrare ordinario nella coda di moderazione e i commentatori che sono stati approvati in precedenza vengono poi approvati automaticamente. I siti con commenti pubblici dovrebbero trattare questa come la correzione prioritaria del rilascio, soprattutto quando la moderazione è delegata o i commentatori abituali vengono ammessi automaticamente.
La cronologia di Patchstack afferma che il problema è stato segnalato al Patchstack Vulnerability Disclosure Program il 15 settembre 2026, convalidato e confermato come comunicato al team WordPress. WordPress 7.1.1 è stato rilasciato il 17 settembre 2026 con la correzione e i backport ai rami supportati precedenti. La cronologia include anche una voce del 18 settembre 2026 che descrive lo stesso rilascio e gli stessi backport, e afferma che la vulnerabilità è stata pubblicata nel database delle vulnerabilità di Patchstack il 18 settembre 2026.
Anche il resto del rilascio di sicurezza è rilevante, sebbene la maggior parte delle altre dieci correzioni richieda un account con un certo livello di privilegi. L’accesso a livello Contributor era sufficiente per una sovrascrittura arbitraria di un post e per un path traversal nel controller dei template della REST API. Una REST API è un’interfaccia web che il software può usare per richiedere o modificare dati. L’accesso a livello Contributor era sufficiente anche per la divulgazione degli slug di post in bozza e in attesa, i brevi nomi adatti agli URL usati negli indirizzi dei post.
Altre correzioni hanno riguardato un problema per cui qualsiasi utente autenticato poteva riassegnare i commenti a un altro genitore, incluse le note, e un problema XML-RPC a livello Author che consentiva di pubblicare post changeset saltando il controllo della capacità custom CSS. XML-RPC è una vecchia interfaccia di controllo remoto che permette al software di comunicare con WordPress. Il rilascio ha anche corretto una stored XSS nelle immagini di intestazione personalizzate su alcuni temi, un problema nell’HTML API che consentiva al testo modificato di uscire da un commento HTML, e un URL appositamente costruito che poteva installare e mostrare in anteprima un tema da WordPress.org.
Anche le installazioni Multisite erano interessate da una correzione. Multisite è una modalità di WordPress in cui un’installazione può eseguire più siti. WordPress 7.1.1 chiude un problema per cui un amministratore del sito poteva attivare a livello di rete un plugin riservato alla rete. Un altro problema di divulgazione di informazioni esponeva il titolo di un post genitore privato.
WordPress 7.1.1 è disponibile tramite Bacheca, Aggiornamenti, o direttamente da WordPress.org. I siti con aggiornamenti automatici in background abilitati dovrebbero riceverlo automaticamente. WordPress ha eseguito il backport delle correzioni ai rami precedenti fino alla 4.7, e le note di rilascio descrivono quale ramo ha ricevuto quale correzione. Patchstack osserva, tuttavia, che solo la versione più recente di WordPress è supportata attivamente, ed è quella che i siti dovrebbero eseguire.
Per i proprietari che non vogliono gestire da soli la sicurezza di WordPress, AEU Hosting è un hosting WordPress gestito, protetto end to end, il che è direttamente rilevante per mantenere un sito aziendale su basi più sicure. Che un sito sia gestito internamente o da un provider, l’azione immediata è la stessa: aggiornare WordPress, controllare le impostazioni dei commenti e assicurarsi che la moderazione dei commenti pubblici non venga considerata l’unica difesa.