Comment2Shell: un commento anonimo può prendere il controllo di…

Il 17 settembre 2026 WordPress ha rilasciato la versione 7.1.1 correggendo CVE-2026-93485, una vulnerabilità stored XSS nel core del CMS che permette a un visitatore

{"main_topic":"vulnerabilita","topics":["cybersecurity","cve","wordpress","rce","patch"]}

Il 17 settembre 2026 WordPress ha rilasciato la versione 7.1.1 correggendo CVE-2026-93485, una vulnerabilità stored XSS nel core del CMS che permette a un visitatore non autenticato di iniettare script malevoli tramite commenti e, se visualizzati da un amministratore loggato, di eseguire codice remoto sul server. Il bug, soprannominato Comment2Shell dal ricercatore che lo ha scoperto, sfrutta un meccanismo di parser differential tra due funzioni di sanitizzazione legacy: wp_kses_post() e wpautop(). La gravità è classificata High con punteggio CVSS 7.1.

Punti chiave

Il payload XSS si attiva per differenza di parsing tra salvataggio e visualizzazione: wp_kses_post() al primo passaggio non riconosce il costrutto come pericoloso, wpautop() al secondo lo riformatta in event handler JavaScript eseguibile.
L'escalation a RCE richiede un amministratore autenticato che apra la pagina del commento: lo script dirotta la sessione per caricare un plugin contenente una web shell.
La moderazione commenti, che WordPress indica come condizione di sfruttabilità, è disabilitata di default nella configurazione standard e il gate del primo commento approvato è bypassabile.
Le versioni affette vanno dalla 4.7 alla 7.1; il fix è disponibile fino alla 4.7.36, ma non sono emerse evidenze di sfruttamento attivo in-the-wild.

Il trucco del line break nel parser differential

La catena di attacco di Comment2Shell si annida in una delle pipeline più antiche e meno scrutinate del core WordPress: il processing dei commenti. Secondo il ricercatore Rafie Muhammad, affiliato al programma Patchstack Bug Bounty, il meccanismo si attiva con "a line break placed inside the attribute of an allowed HTML tag in the comment". Il payload sfrutta un tag HTML consentito nella whitelist dei commenti — il dossier menziona area come esempio — e posiziona un carattere di a capo strategico all'interno di un attributo.

La prima fase di sanitizzazione, eseguita da wp_kses_post() al momento del salvataggio nel database, analizza il markup e lo ritiene pulito perché il line break impedisce il riconoscimento del pattern pericoloso. La seconda fase, eseguita da wpautop() alla visualizzazione della pagina, inserisce tag <p> e riformatta il contenuto. Questa riformattatura sposta il line break, ricompattando l'attributo in un event handler JavaScript valido — per esempio onerror o onload — che il browser esegue nel contesto della pagina.

Il risultato è una stored XSS: il payload persiste nel database e si attiva ogni volta che un utente carica la pagina del commento. La natura "stored" rende l'attacco più pericoloso di un XSS riflesso: non richiede ingegneria sociale diretta né URL confezionati, basta che la vittima visiti una pagina legittima del sito.

Da commento a shell: l'hijacking della sessione admin

L'iniezione JavaScript da sola non garantisce l'esecuzione remota di codice sul server. La escalation avviene attraverso il dirottamento della sessione autenticata di un amministratore di WordPress. Quando un utente con privilegi elevati — tipicamente un amministratore che gestisce i commenti in sospeso o semplicemente visualizza il thread — carica la pagina, lo script iniettato opera con i permessi della sua sessione nel browser.

Con questi privilegi, il payload può eseguire chiamate autenticate all'API di amministrazione di WordPress per caricare e attivare un plugin arbitrario. The Hacker News riporta esplicitamente che lo script "could then use the administrator's own session to upload a plugin containing a web shell". Questo trasforma una falla di presentazione — l'XSS — in compromissione completa dell'host, con accesso al filesystem e capacità di eseguire comandi PHP arbitrari.

Il vettore funziona sia sui temi a blocchi introdotti con il progetto Gutenberg, sia sui temi classici che formattano i commenti con wpautop(). La superficie di attacco non è quindi ristretta a una specifica generazione di temi o a un sottoinsieme di installazioni.

La moderazione come falso confine di sicurezza

Un punto critico del dossier riguarda la posizione di WordPress.org sulle condizioni di sfruttamento. L'advisory ufficiale del vendor descrive la falla come "subject to comment approval". Tuttavia, la configurazione di default di WordPress non richiede la moderazione dei commenti: ogni visitatore può lasciare un commento senza approvazione preventiva, salvo il filtro del primo commento di un nuovo utente.

Patchstack ha formalmente contestato questa cornice: secondo la fonte, "moderation isn't a security control". Il primo commento di un utente non verificato richiede approvazione, ma una volta superato questo gate — con un commento innocuo preliminare o con altre tecniche — tutti i commenti successivi vengono pubblicati automaticamente. L'attaccante può quindi costruire una cronologia di interazioni apparentemente lecite prima di iniettare il payload finale.

Questa dinamica rende il percorso di attacco praticabile senza interazione umana preventiva da parte dell'amministratore, al di là della sola visualizzazione finale che scatena l'RCE. La moderazione non elimina il rischio, al massimo lo ritarda.

"The trick was a line break placed inside the attribute of an allowed HTML tag in the comment"

Cosa fare adesso

Il rilascio 7.1.1 di WordPress, pubblicato il 17 settembre 2026, corregge Comment2Shell insieme ad altri 10 problemi di sicurezza. Il fix è stato backportato fino alla versione 4.7.36. L'azione prioritaria per gli amministratori di siti WordPress è l'aggiornamento immediato alla 7.1.1 o all'ultima versione di backport disponibile per il proprio branch.

Per le organizzazioni con gestione centralizzata di flotte di siti WordPress: la vulnerabilità è nel core, non in un plugin di terze parti. Nessuna configurazione di sicurezza a livello di plugin aggiuntivo elimina la falla; la correzione richiede il patch del codice base. Le versioni dalla 4.7 alla 7.1 sono tutte affette.

Il monitoring dei log di accesso all'interfaccia di amministrazione /wp-admin/plugin-install.php e /wp-admin/update.php può rivelare caricamenti di plugin non autorizzati effettuati da sessioni amministrative esistenti, sebbene il dossier non documenti indicatori di compromissione specifici per questo vettore.

Infine, la limitazione dell'accesso ai pannelli di moderazione commenti e plugin a indirizzi IP specifici, dove operativamente fattibile, riduce la probabilità che un amministratore visualizzi il commento malevolo da un contesto di sessione privilegiata.

Un pattern ricorrente: la sanificazione come superficie d'attacco

Comment2Shell non è un incidente isolato nel calendario delle vulnerabilità WordPress. Il 2026 ha già registrato un precedente della stessa classe: XSS2Shell (CVE-2026-64638, agosto), una reflected XSS in wp-login.php che sfruttava un differential tra strip_tags() e wp_kses_post(). Comment2Shell sposta lo stesso principio nel dominio dei commenti, con la complicazione aggiuntiva della persistenza.

Entrambi i bug emergono dalla stessa radice strutturale: la complessità della pipeline di sanitizzazione di WordPress, cresciuta organicamente su quasi due decenni di sviluppo, con funzioni legacy che interagiscono in modi non previsti dai singoli autori. La domanda che il dossier solleva implicitamente — e che gli operatori di sicurezza devono ora affrontare esplicitamente — è quanti altri parser differential restino nascosti in questa stratigrafia di codice.

Per un CMS che alimenta oltre il 43% del web, la sicurezza del core non è più un problema di singole installazioni. È un rischio sistemico.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter