WordPress Click2Shell: un clic di admin apre la RCE su milioni…

Una vulnerabilità CSRF nel core di WordPress consente l'installazione forzata di temi inattivi e l'esecuzione remota di codice PHP. La patch 7.1.1 è disponibile dal

Il 17 settembre 2026 WordPress ha rilasciato la versione 7.1.1 correggendo una vulnerabilità nel proprio core che permette a un attaccante non autenticato di costringere un amministratore loggato a installare un tema arbitrario dal catalogo ufficiale WordPress.org, aprendo la strada all'esecuzione remota di codice PHP sul server. La falla, ribattezzata Click2Shell dai ricercatori di pwn.ai che l'hanno scoperta e divulgata, sfrutta una discrepanza tra parsing lato server e interpretazione lato client che nessuno aveva finora mappato come superficie d'attacco. Con WordPress che alimenta circa il 43% dell'intero web, la posta in gioco supera i confini della singola installazione.

Punti chiave

Il root cause è un'iniezione di selettore jQuery nella schermata di anteprima temi di wp-admin: il parametro URL viene canonizzato dalle API di WordPress.org ma preservato con la punteggiatura originale nel selettore JavaScript eseguito nel browser dell'amministratore.
La catena completa raggiunge la massima criticità: CVSS 3.1 7.1 per la primitiva CSRF di installazione forzata da sola, e CVSS 3.1 9.3-9.6 per l'esecuzione remota di codice concatenata con un tema vulnerabile.
Il tema installato tramite l'attacco rimane inattivo e invisibile sul sito pubblico, ma WordPress esegue comunque il suo functions.php durante l'anteprima Customizer, creando una superficie d'esecuzione nascosta.
La correzione, contenuta nel changeset 63664, restringe il matching agli elementi div.theme e applica l'escaping dello slug derivato dall'URL prima che entri in sintassi di selettore jQuery.

Il doppio parsing che inganna WordPress e l'amministratore

Paulos Yibelo di pwn.ai ha individuato il meccanismo fondamentale nell'architettura di anteprima temi del pannello di amministrazione. Quando un amministratore visita un URL costruito ad arte, il parametro del tema subisce due trattamenti incongruenti: da una parte le API di WordPress.org ne normalizzano lo slug togliendo caratteri speciali, dall'altra il file wp-admin/js/theme.js lo inserisce direttamente in un selettore jQuery mantenendo intatta la punteggiatura originale.

Questa discrepanza permette di iniettare sintassi selettore arbitraria. Il payload dimostrativo, come riportato nel report tecnico di pwn.ai, utilizza la stringa twentytwenty\"]>*>*>/* per uscire dal contesto del selettore originale e raggiungere i controlli d'azione, in particolare il pulsante Install. Il risultato, nelle parole stesse dei ricercatori, è "un'anteprima tema che clicca Install da sé". Nessun clic consapevole da parte dell'amministratore, nessuna conferma esplicita.

WordPress ha riconosciuto pubblicamente la natura della falla. Nelle release notes della versione 7.1.1, come citate da The Hacker News, si legge: "URL specialmente costruiti possono installare automaticamente e visualizzare in anteprima un tema inattivo da WordPress.org". La stessa fonte riporta la distinzione esplicita operata dai ricercatori: "Il bug di Core non accetta da sé un ZIP tema arbitrario". L'installazione forzata si limita ai temi presenti nel catalogo ufficiale.

"Un valore da un URL di anteprima tema WordPress viene interpretato una volta dalle API Temi di WordPress.org e una seconda volta, con metodi difettosi, dal JavaScript nel browser dell'Amministratore." — Paulos Yibelo/pwn.ai, riportato da BleepingComputer

L'anteprima Customizer come motore di esecuzione nascosto

Il passaggio cruciale della catena d'esplosione risiede in un comportamento del core finora sottovalutato dai team di sicurezza: WordPress carica il PHP di un tema anche durante l'anteprima Customizer, quando il tema è ancora inattivo e un altro tema rimane attivo sul sito visibile. Questo significa che il codice malevolo contenuto in functions.php — o in altri file inclusi — viene eseguito sul server senza che il tema venga mai attivato pubblicamente.

I ricercatori di pwn.ai hanno dimostrato la catena completa sfruttando il tema Mobile Repair Zone versione 2.5.4, che presentava un handler AJAX privo di verifica nonce o di controllo sulle capacità utente. L'handler recuperava dettagli di plugin controllati dall'attaccante, completando così l'escalation fino all'esecuzione arbitraria di codice PHP remoto. Il sito pubblico non mostrava alcuna modifica: il tema rimaneva inattivo, ma il server era già compromesso.

La natura stealth dell'attacco rende particolarmente insidioso il rilevamento. Nessun cambiamento visibile, nessun tema attivo sospetto, nessuna notifica di installazione che attiri l'attenzione. L'unica traccia residua è l'esistenza di un tema aggiuntivo nella directory wp-content/themes, facilmente confondibile con installazioni dimenticate o di test.

Il cieco spot dei temi inattivi e la scoperta di pwn.ai

La ricerca di pwn.ai ha portato alla luce una dimensione sistemica del problema. Oltre al caso dimostrativo di Mobile Repair Zone, i ricercatori hanno identificato oltre 40 temi di terze parti nel catalogo WordPress.org con vulnerabilità simili di pre-attivazione: handler AJAX, inclusioni arbitrarie o esecuzione di codice attivabili prima ancora che il tema diventi attivo sul sito. Questo ampio campione conferma che la superficie d'attacco non si limita a un singolo prodotto difettoso, ma riguarda un pattern architetturale diffuso.

La scoperta è stata segnalata a WordPress il 22 agosto 2026. Dopo quasi quattro settimane di lavorazione, il fix è stato rilasciato il 17 settembre 2026 nella versione 7.1.1, che include complessivamente 11 correzioni di sicurezza. Il changeset 63664, analizzato sia da pwn.ai che da CyberPress, implementa due contromisure complementari: il vincolo del matching dell'anteprima agli elementi div.theme — escludendo quindi selettori che puntano a controlli d'azione — e l'applicazione di $.escapeSelector() sullo slug derivato dall'URL prima del suo inserimento nella sintassi jQuery.

WordPress ha riconosciuto la gravità della segnalazione erogando la ricompensa massima prevista dal proprio programma bug bounty, come confermato dal report di pwn.ai. Al momento della divulgazione non risultava ancora assegnato un identificatore CVE ufficiale, sebbene le fonti indichino l'intenzione di WordPress di procedere all'assegnazione.

Cosa fare adesso

Aggiornare immediatamente a WordPress 7.1.1: la release del 17 settembre 2026 contiene la correzione definitiva per tutte le versioni interessate dal 6.0 al 7.1.0 inclusi.
Rivedere i temi presenti in wp-content/themes eliminando quelli inattivi non necessari: ogni tema inattivo rappresenta una superficie d'esecuzione potenziale durante l'anteprima Customizer.
Verificare che la costante DISALLOW_FILE_MODS sia attiva negli ambienti dove non sia richiesta l'installazione dinamica di temi o plugin, poiché questa configurazione blocca la primitiva di installazione forzata.
Riordinare la priorità delle patch: la consueta attenzione ai soli temi attivi è insufficiente; i controlli di sicurezza devono estendersi a tutti i temi installati, inclusi quelli dormienti.

Una ricalibrazione del rischio tema inattivo

Click2Shell non è semplicemente una nuova vulnerabilità da catalogare e dimenticare. � una dimostrazione che l'architettura di Customizer di WordPress ha creato, di fatto, una zona franca di esecuzione PHP separata dalla logica di attivazione tema su cui i professionisti della sicurezza avevano costruito le proprie assunzioni. La distinzione tra tema attivo e tema inattivo, finora considerata barriera sufficiente, si rivela permeabile attraverso un percorso di anteprima progettato per la comodità dell'amministratore.

La disponibilità pubblica del proof-of-concept di pwn.ai, combinata con la semplicità del vettore iniziale — un link cliccabile via email, messaggio o social engineering — richiede una risposta tempestiva. L'assenza di evidenze di sfruttamento in-the-wild al momento della divulgazione, come riportano esplicitamente le fonti, offre una finestra di mitigazione che si restringe con la diffusione dei dettagli tecnici.

Domande frequenti

Perché il tema installato rimane inattivo?: La primitiva CSRF sfrutta la schermata di anteprima, non il flusso di attivazione. Il tema viene scaricato e reso disponibile per l'anteprima Customizer, ma WordPress non lo imposta come tema corrente del sito. Questa invisibilità è ciò che rende l'attacco stealth.
Può un attaccante installare un tema non presente su WordPress.org?: No. Secondo la fonte primaria pwn.ai, il bug di Core non accetta autonomamente un archivio ZIP arbitrario. L'installazione forzata è limitata ai temi pubblicati nel catalogo ufficiale WordPress.org.
I ruoli Editor o Author possono innescare la catena?: No. Patchstack ha confermato che solo il ruolo di Amministratore dispone della capability install_themes necessaria a scatenare la sequenza. Ruoli inferiori non possono attivare la primitiva anche se cliccano il link malevolo.

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

Fonti

Fonti e riferimenti

Ricevi DeafLetter