Click2Shell è una catena di vulnerabilità di WordPress che parte da un semplice link e finisce con l'esecuzione di codice PHP sul server. Basta che un amministratore con la sessione aperta apra l'indirizzo giusto. Il sito installa un tema da solo, senza clic sul pulsante e senza conferma. Da quel tema si può arrivare a far girare codice scritto da altri. L'ha divulgata il 18 settembre 2026 il team pwn.ai, il giorno dopo l'uscita di WordPress 7.1.1, la versione che chiude il difetto.
Faccio manutenzione su siti WordPress di clienti da anni. Quando è uscita la notizia, la prima cosa che ho fatto è stata passare in rassegna i siti che seguo: versione del Core, elenco dei temi installati, plugin comparsi di recente. In questo articolo ti spiego come funziona Click2Shell in termini che puoi capire anche se non sei uno sviluppatore, quali versioni sono colpite e i cinque controlli da fare oggi sul tuo sito.
Cos'è Click2Shell e perché il nome
Il nome è un omaggio ai predecessori, wp2shell e xss2shell. La somiglianza però si ferma presto. wp2shell, la falla di luglio 2026, non chiedeva nessun login ed è stata sfruttata attivamente. Click2Shell ha bisogno che un amministratore già autenticato apra il link. È una differenza sostanziale, e la vedrai nei numeri più avanti.
La segnalazione porta la firma del team pwn.ai, che scrive di aver condotto la ricerca con un harness proprio, Claude Opus 5 e un ricercatore umano. WordPress ha riprodotto il problema lo stesso giorno della segnalazione, il 22 agosto 2026, e ha pagato la taglia massima del suo programma: 300 dollari. Per un software che fa girare circa il 43% del web, è una cifra che dice molto sui budget del bug bounty di un progetto open source.
Come funziona Click2Shell: tre falle, una sola catena
I pezzi sono tre e nessuno dei tre, da solo, porta all'esecuzione di codice. Il primo sta nel Core di WordPress. Il secondo è una funzione legittima del Customizer usata al rovescio. Il terzo è un tema di terze parti scaricato dal catalogo ufficiale. Montati in sequenza fanno quello che il nome promette.
1. Il link che preme "Installa" al posto tuo
La pagina /wp-admin/theme-install.php accetta un parametro theme che indica quale tema mostrare. Il file JavaScript dell'installatore, wp-admin/js/theme.js, infilava quel valore dentro un selettore jQuery senza filtrarlo:
// prima della 7.1.1: lo slug arriva dall'URL senza filtri
$( 'div[data-slug="' + slug + '"]' ).trigger( 'click' );
// dalla 7.1.1 (changeset 63664): selettore vincolato e slug sanificato
$( 'div.theme[data-slug="' + $.escapeSelector( slug ) + '"]' ).trigger( 'click' );Con uno slug costruito per chiudere in anticipo il selettore, questo smette di puntare alla singola scheda del tema. Si allarga ai controlli di installazione che la pagina tiene nascosti. A quel punto è lo stesso JavaScript di WordPress a premere il pulsante Installa, con i cookie e i permessi dell'amministratore che ha aperto il link. Il tema che finisce su disco è uno dei pacchetti pubblicati su WordPress.org, non un file arbitrario caricato da fuori.
2. Il codice del tema gira prima dell'attivazione
Qui non c'è un bug, c'è un comportamento documentato. Quando chiedi l'anteprima di un tema dal Customizer, WordPress carica il PHP di quel tema anche se resta attivo un altro. Serve a mostrare la preview, e per farlo il codice deve girare davvero.
Questa è la parte che mi ha fatto riflettere di più. Chi amministra WordPress da qualche anno considera un tema inattivo un pacchetto morto, un archivio fermo dentro wp-content/themes/. Nella pratica non lo è. Un tema installato ma mai attivato può registrare i suoi hook e i suoi endpoint dentro la sessione del pannello. Click2Shell è il promemoria più chiaro che ho visto su questo punto.
3. L'endpoint AJAX che installa un plugin da un URL
Il terzo tassello arriva da Mobile Repair Zone, un tema del catalogo WordPress.org nella versione 2.5.4. Il tema registrava un'azione AJAX che installa e attiva un plugin. Ogni azione di questo tipo dovrebbe verificare due cose: un nonce (il gettone monouso che dimostra che la richiesta arriva dal pannello) e una capability (il permesso dell'utente). Quel gestore non controllava né l'uno né l'altro. Prendeva dalla richiesta l'indirizzo del pacchetto, scaricava lo zip, lo scompattava nella cartella dei plugin e caricava il file scelto da chi aveva mandato la richiesta.
Il dettaglio meno rassicurante lo scrive pwn.ai quasi di passaggio. Lo stesso schema di endpoint sprotetto è stato trovato in oltre 40 temi di terze parti ospitati su WordPress.org, e non esiste un elenco pubblico. Mobile Repair Zone conta poche decine di installazioni: il singolo tema non è il problema, il problema è la famiglia.
Perché si parla di "pre-auth" se serve un amministratore loggato
Si parla di pre-auth perché l'attaccante non ha bisogno di nessun account sul sito bersaglio, né di credenziali rubate. Gli serve una cosa diversa: che un amministratore già autenticato apra il suo link. Da lì in poi tutto è automatico.
La distinzione si vede nei punteggi. Pwn.ai valuta il solo forzamento dell'installazione come severità alta, CVSS 3.1 pari a 7,1. La catena Click2Shell completa sale a potenzialmente critica, 9,3. Il vettore "interazione dell'utente richiesta" tiene giù il punteggio. Patchstack classifica il difetto del Core come CSRF, una richiesta forgiata che sfrutta la sessione della vittima.
Una nota: in rete girano già proof of concept pubblici di Click2Shell. Qui non li trovi e non li linko. Un exploit pronto non aggiunge niente a chi deve difendere un sito.
Versioni colpite e dove è corretta
| Componente | Versione vulnerabile | Dove è corretto |
|---|---|---|
| WordPress Core (installatore temi) | tutte le versioni precedenti alla 7.1.1 | WordPress 7.1.1 del 17 settembre 2026 |
| Rami ancora supportati | il changelog non indica quali rami siano colpiti | 7.0.5, 6.9.8, 6.8.9, 6.7.8 e le altre release di ramo fino al 4.7.36 |
| Tema Mobile Repair Zone | 2.5.4 e precedenti | 2.5.5, aggiornata il 9 settembre 2026 |
| Altri temi con lo stesso endpoint AJAX | oltre 40 pacchetti secondo pwn.ai | nessun elenco pubblicato: si aggiorna tutto e si controlla a mano |
Il difetto del Core riguarda tutte le versioni di WordPress precedenti alla 7.1.1, uscita il 17 settembre 2026 insieme ad altre dieci correzioni di sicurezza. Il progetto ha pubblicato aggiornamenti anche per i rami più vecchi. Chi resta su un ramo precedente per compatibilità con un plugin ha quindi comunque un aggiornamento da installare.
I 5 controlli che faccio sui siti dei clienti contro Click2Shell
Nessuno di questi richiede competenze da sviluppatore. Li metto in ordine di urgenza, non di comodità. È la stessa checklist che sto applicando sui siti che seguo in manutenzione.
1. Aggiorna il Core di WordPress
Bacheca, poi Aggiornamenti, e porta il sito alla 7.1.1. Se sei fermo su un ramo precedente per un plugin che non regge le versioni nuove, installa la release di sicurezza di quel ramo (7.0.5, 6.9.8, 6.8.9 e così via). Sono aggiornamenti minori che non cambiano le funzioni. Se gli aggiornamenti automatici sono attivi il sito potrebbe essere già a posto, ma va verificato, non dato per fatto. Il Core è il passaggio che rompe la catena di Click2Shell.
2. Guarda l'elenco dei temi installati, non solo quello attivo
In Aspetto, Temi, cerca pacchetti che non ricordi di aver scelto. Il primo passaggio di Click2Shell lascia proprio questa traccia: un tema del catalogo ufficiale comparso senza che nessuno lo abbia chiesto. Se c'è, rimuovilo e ricostruisci la cronologia degli accessi amministrativi.
3. Aggiorna i temi, compresi quelli inattivi (o cancellali)
Se usi Mobile Repair Zone, la 2.5.5 è quella da avere. Per gli altri vale la regola che applico da sempre: un tema che non serve si cancella invece di tenerlo fermo in una cartella. Il suo PHP può girare anche senza attivazione. Su molti siti che prendo in carico trovo tre o quattro temi di default mai rimossi.
4. Controlla i plugin comparsi di recente
L'ultimo anello di Click2Shell installa un plugin da un indirizzo remoto. Un pacchetto che non hai mai scaricato è quindi il segnale più diretto. Guarda anche dentro wp-content/mu-plugins/: i must-use plugin si attivano da soli e non compaiono nell'elenco normale, per questo sono il nascondiglio preferito delle backdoor.
5. Chiudi la sessione da amministratore quando non ti serve
Tutta la catena si regge su un cookie valido nel browser che apre il link. Navigare con la sessione di amministrazione sempre aperta, magari nella stessa finestra in cui leggi la posta, è l'abitudine che rende sfruttabile questa classe di problemi. È la cosa più difficile da far passare ai clienti, e la più efficace.
Se dai controlli emerge qualcosa che non torna, il sito va trattato come compromesso. La procedura è quella di sempre: chiavi di sicurezza rigenerate, password cambiate, confronto dei file con una copia pulita. Ho descritto i tre controlli rapidi per capire se sei già stato bucato nell'articolo sulla vulnerabilità di Elementor Pro, e valgono anche qui.
E se l'aggiornamento rompe qualcosa?
È la paura che sento più spesso, e nei forum WordPress di questi giorni è la domanda più frequente: "aggiorno e poi il tema non funziona più". È un timore fondato per i salti di versione grossa. Per la 7.1.1 no: è una release di sicurezza, tocca undici punti precisi e non cambia le funzioni. Rimandarla per paura lascia aperta una porta per cui esiste già codice pubblico.
Tre accorgimenti che uso sempre prima di aggiornare:
- Backup completo prima di partire, file e database. Se il tuo hosting fa snapshot giornalieri, verifica che l'ultimo sia riuscito.
- Prova su staging se il sito è un ecommerce o ha plugin pesanti. Molti hosting lo offrono con un clic; in alternativa una copia locale basta.
- Se compare "errore critico" dopo l'aggiornamento, WordPress manda un'email con un link alla modalità di ripristino. Da lì disattivi il plugin o il tema che ha causato il problema. Se l'email non arriva, rinomini via FTP la cartella del plugin sospetto in
wp-content/plugins/e il sito riparte.
Se l'aggiornamento fallisce perché il sito è bloccato su una versione vecchia per un plugin incompatibile, non forzare il salto: installa la release di sicurezza del tuo ramo e programma la migrazione con calma.
Quanto pesa Click2Shell rispetto a wp2shell
Il confronto con luglio serve a calibrare la reazione. wp2shell è la catena formata da CVE-2026-63030 e CVE-2026-60137, pubblicata il 17 luglio 2026. Colpiva WordPress dalla 6.9.0 alla 6.9.4 e dalla 7.0.0 alla 7.0.1. Funzionava senza login e senza interazione, combinando una confusione di rotta nella REST API con una SQL injection. Quattro giorni dopo la pubblicazione la CISA l'ha inserita nel catalogo KEV, l'elenco delle vulnerabilità sfruttate attivamente. CrowdSec ha contato oltre 62.000 indirizzi IP distinti impegnati a provarci in quindici giorni.
Click2Shell no. Al 22 settembre 2026 nessuna fonte riporta tentativi reali e non esiste un CVE assegnato. Per chi tiene i siti aggiornati la finestra di rischio si è aperta e chiusa in un giorno, perché la correzione è arrivata prima della divulgazione tecnica.
Resta un fatto che vale più della singola catena. Sia wp2shell sia Click2Shell nascono da un pezzo di WordPress che tutti guardano poco: la REST API nel primo caso, l'installatore dei temi nel secondo. Nella stessa 7.1.1 ci sono undici correzioni di sicurezza, con segnalazioni arrivate anche da Anthropic e da ricercatori esterni. Il Core è sotto osservazione, e aspettarsi meno segnalazioni nei prossimi mesi sarebbe una scommessa strana. Ne ho parlato anche a proposito del threat report di Anthropic, che cita gli exploit WordPress tra i vettori più usati.
Cosa mi porto a casa da Click2Shell
Il selettore jQuery è un errore classico, chiuso con una riga di codice e una funzione che esisteva già in jQuery. Il pezzo che conta davvero è il secondo anello, quello che nessuno chiamerebbe vulnerabilità. Un tema inattivo che esegue il suo PHP durante un'anteprima è una funzione, non un bug, e per questo nessuno la guardava come superficie d'attacco.
Se il dato di pwn.ai regge, i quaranta e più temi con lo stesso endpoint aperto dicono che il catalogo di WordPress.org ha un problema di controllo qualità sul codice di terze parti. Quel buco nessuna patch del Core lo chiude. È il motivo per cui, quando prendo in carico un sito, la prima cosa che faccio è ridurre: meno temi, meno plugin, meno superficie. Ed è il motivo per cui la manutenzione di un sito non è "aggiornare quando capita" ma una routine con date e responsabilità.
Se hai un sito WordPress e non sai a che versione è, o se vuoi che qualcuno faccia questi cinque controlli al posto tuo, scrivimi: rispondo io e in una mattinata il sito è verificato e aggiornato.
