wp2shell: perché il sito WordPress dimenticato è la porta d'ingresso più comoda

Il sito dell’associazione, fatto qualche anno fa da un volontario. Il sito vetrina della PMI, affidato a un’agenzia che nel frattempo ha chiuso. La pagina WordPress della scuola per gli eventi, che nessuno aggiorna da mesi. Sono esattamente i siti che una campagna scoperta in questi giorni ha usato come punto d’ingresso.

Secondo quanto riportato ieri da BleepingComputer, sulla base di un’analisi di GreyNoise, un gruppo probabilmente di lingua cinese ha compromesso almeno 49 organizzazioni in 29 Paesi sfruttando due vulnerabilità di WordPress note come “wp2shell”. Le vittime sono soprattutto piccole imprese ed enti pubblici. In un caso, un ente governativo occidentale, sono stati sottratti oltre 18.500 record con dati personali e password in chiaro.

Cos’è wp2shell, in parole semplici

wp2shell è una catena di due falle nel nucleo di WordPress, non in un plugin. È un dettaglio importante: non basta “avere pochi plugin” per sentirsi al sicuro.

La prima falla (CVE-2026-63030) riguarda il modo in cui WordPress gestisce alcune richieste multiple inviate alla sua interfaccia REST. La seconda (CVE-2026-60137) è una SQL injection, cioè la possibilità di “infilare” comandi nel database del sito. Messe insieme, permettono a un attaccante senza alcuna credenziale di eseguire codice sul server e prendere il controllo completo del sito.

Le correzioni sono uscite a metà luglio. Come ricostruiscono Rapid7 e Wiz, sono vulnerabili le versioni dalla 6.9.0 alla 6.9.4 e dalla 7.0.0 alla 7.0.1; le versioni sicure sono la 6.9.5 e la 7.0.2 (per il ramo 6.8 serve almeno la 6.8.6). Pochi giorni dopo sono comparsi exploit pubblici e l’agenzia statunitense CISA ha inserito entrambe le falle nel suo catalogo delle vulnerabilità sfruttate attivamente.

In altre parole: la patch c’è da due mesi. Chi è stato colpito, nella grande maggioranza dei casi, semplicemente non aveva aggiornato.

Cosa fanno gli attaccanti una volta dentro

La parte che dovrebbe far riflettere è ciò che succede dopo. Dalla ricostruzione di GreyNoise emerge uno schema preciso:

• installano una webshell, un piccolo file che permette di tornare sul server quando vogliono, anche dopo l’aggiornamento;
• creano un account amministratore camuffato, con un nome che sembra legittimo;
• cercano nei file del sito le credenziali del database e di altri servizi;
• usano quelle credenziali per muoversi verso altri sistemi interni e provare le stesse password altrove.

È qui che un “semplice sito vetrina” diventa un problema aziendale. Quando aiutiamo un cliente dopo un incidente, in Security Smart vediamo spesso siti ospitati sullo stesso server di altri servizi, password del database riutilizzate per la posta o per il gestionale, moduli di contatto che salvano nel database nomi, email e telefoni. Tutto materiale che finisce nelle mani sbagliate.

Lo stesso gruppo, sempre secondo BleepingComputer, ha colpito anche quasi mille switch di rete Zyxel, molti dei quali ancora con le credenziali di fabbrica. Il filo conduttore è lo stesso: dispositivi e servizi installati e poi dimenticati.

Aggiornare non basta, se il sito è già stato violato

Un punto che spesso sfugge: se il sito è rimasto vulnerabile tra luglio e oggi, aggiornare WordPress chiude la porta, ma non caccia chi potrebbe essere già entrato. Webshell e utenti amministratori creati di nascosto sopravvivono all’aggiornamento.

C’è anche un risvolto GDPR. Se il sito conteneva dati personali (iscrizioni, moduli, area riservata soci o famiglie) e si scopre una compromissione, si tratta di una violazione da valutare ed eventualmente notificare al Garante entro 72 ore dalla scoperta. Meglio saperlo prima di trovarsi a gestirlo di corsa.

Cosa fare, in pratica

• Verificate oggi la versione di WordPress. Dalla bacheca, alla voce Aggiornamenti, controllate di essere almeno alla 6.9.5 o alla 7.0.2 (6.8.6 se siete sul ramo 6.8). Se il sito è gestito da un fornitore, chiedetegli una conferma scritta.
• Controllate gli utenti amministratori. Aprite l’elenco utenti, filtrate per ruolo “Amministratore” ed eliminate o indagate qualunque account che non riconoscete o che è stato creato di recente.
• Fate cercare file sospetti sul server. Chiedete all’hosting o al vostro tecnico una scansione alla ricerca di webshell e di file PHP modificati o aggiunti da luglio in poi, soprattutto nelle cartelle dei caricamenti.
• Cambiate le credenziali collegate al sito. Password del database, account amministratori, accesso FTP e pannello dell’hosting: se il sito era vulnerabile, consideratele potenzialmente note a terzi. E non riutilizzatele altrove.
• Fate l’inventario di ciò che è esposto su Internet. Siti vecchi, sottodomini di progetti conclusi, apparati di rete con password di fabbrica: ciò che non serve va spento, ciò che serve va aggiornato con regolarità e affidato a qualcuno che ne risponde.

Matteo Gianniello — Consulente privacy e cyber security