Il tuo sito WordPress è stato violato? Come capirlo in 5 minuti

La telefonata arriva di mattina. Dall’altra parte c’è un imprenditore che ha appena ricevuto una email dai suoi fornitori. La sintesi è questa: abbiamo messo il vostro sito offline.

Non per un guasto. Per sicurezza. I sistemi di monitoraggio internazionali avevano segnalato che il suo sito aziendale, un sito serio, di un’azienda di consulenza vera, con clienti veri, stava servendo pagine di scommesse in lingua turca.

Lui non ne sapeva niente. Il sito, aperto dal suo browser, era perfetto.

Ed era esattamente quello il punto.

Il trucco: due siti dentro lo stesso sito

Chi era entrato aveva usato una tecnica che si chiama cloaking, e in italiano suona come quello che è: mascheramento.

Il codice malevolo controlla chi sta chiedendo la pagina.

• Se sei una persona con un browser normale, vedi il sito aziendale. Impeccabile.
• Se sei Google, vieni spedito su pagine fraudolente in turco.

Il titolare apriva il suo sito ogni giorno e stava tranquillo. Google vedeva un sito di scommesse e lo indicizzava come tale, bruciando in silenzio l’autorevolezza di un dominio costruito in anni di lavoro. Il proprietario è sempre l’ultimo a saperlo, perché è l’unico a cui il sito viene mostrato pulito.

Cosa c’era dentro

Abbiamo preso il sito e abbiamo calcolato l’impronta digitale di ogni suo singolo file: 15.060, uno per uno, per poter dimostrare dopo cosa era stato toccato e cosa no. Poi siamo andati a fondo.

Non era un attacco. Erano tre, sovrapposti sullo stesso impianto, e il più vecchio risaliva a febbraio 2023.

Tre anni. Il sito era compromesso da tre anni e nessuno se n’era mai accorto.

Dentro c’erano:

• una webshell: un pannello di controllo nascosto che permette a un estraneo di eseguire comandi sul server come se fosse seduto lì davanti;
• tre backdoor a parola d’ordine, file che sembrano innocui e si attivano solo per chi arriva con la chiave giusta, così un controllo superficiale non vede niente;
• tre programmi per caricare altri file, cioè il modo di rientrare dopo essere stati cacciati;
• una campagna spam per un finto negozio giapponese, e un centinaio di articoli-spazzatura infilati nel database con dentro codice che provava a svuotare i portafogli di criptovalute dei visitatori.

Il punto d’ingresso più probabile: un plugin fermo a una versione di tre anni prima. Uno solo.

Abbiamo ripulito tutto, documentato ogni passaggio con la catena degli hash prima e dopo, e rimesso il sito online senza perdere un contenuto. Oggi quel sito è ospitato da noi, aggiornato e sorvegliato.

Poi, il 17 luglio, quella lezione ha smesso di bastare

Per anni la morale di quella vicenda sarebbe stata semplice: tieni aggiornati i plugin e non ti succede.

Il 17 luglio 2026 WordPress ha pubblicato una versione di emergenza e il team di WordPress.org ha fatto una cosa che fa raramente: ha forzato l’installazione dell’aggiornamento sui siti di mezzo mondo, senza chiedere il permesso a nessuno.

Il motivo si chiama wp2shell.

Perché è un’altra categoria di problema

Il sito dell’imprenditore era stato bucato per colpa di un plugin vecchio. È lo scenario classico: c’è una causa, c’è qualcosa che si poteva fare.

wp2shell funziona su un WordPress appena installato. Senza un solo plugin. Senza un tema particolare. Senza password deboli. Senza che nessuno sbagli niente.

Serve solo che il sito esista e sia raggiungibile da internet.

Sono due difetti di WordPress stesso, incatenati fra loro:

• CVE-2026-63030, una confusione nel modo in cui WordPress smista le richieste su una porta di servizio interna chiamata batch/v1, presente in ogni installazione;
• CVE-2026-60137, un’iniezione SQL: la possibilità di far eseguire al database comandi scritti da chi attacca.

Il primo apre la porta, il secondo scrive nel database. Sono stati segnalati rispettivamente da Adam Kues (Assetnote/Searchlight Cyber) e da TF1T, dtro e haongo, citati per nome nell’annuncio ufficiale di WordPress.

La parte che spiazza: l’amministratore non viene “creato”

Quando qualcuno si registra su WordPress scattano dei campanelli interni: partono le email, i plugin di sicurezza se ne accorgono, resta traccia.

Con wp2shell non scatta niente, perché l’account non passa da WordPress: viene scritto direttamente nel database. È come se qualcuno, invece di entrare dalla porta e firmare alla reception, riscrivesse a penna il registro degli ospiti.

Per il sito, quell’amministratore c’è sempre stato. Nessuna notifica, nessuna traccia nei registri di accesso, nessun plugin di sicurezza che si accorge di nulla, perché i plugin ascoltano i campanelli, e i campanelli non hanno suonato.

Gli account creati con lo strumento pubblico hanno un nome che inizia per w2s_ e un’email che finisce per @wp2shell.local. Ma è solo la configurazione predefinita: cambiarla è banale, e in giro se ne vedono di camuffati da persone normali, con l’email del dominio del sito su cui compaiono.

La trappola: “ma io ho gli aggiornamenti automatici”

Ed è qui la parte che quasi nessuno ha raccontato.

WordPress.org ha spinto l’aggiornamento il 17 luglio. Non lo ha proposto: lo ha imposto. Eppure, nelle settimane successive, controllando installazioni che ci vengono affidate, ne abbiamo trovate ancora ferme alla versione bucata.

Non per pigrizia di chi le curava, ma per una ragione tecnica che quasi nessuno conosce: erano troppo protette.

Su un sito configurato bene, i file di WordPress non appartengono all’utente che esegue il sito. È una precauzione elementare: se un attaccante riesce a far eseguire del codice, esattamente come nella storia di prima, quel codice non può riscrivere i file. È la stessa logica per cui in un ristorante il cameriere non ha le chiavi della cassa.

Solo che l’aggiornamento automatico di WordPress è codice che gira dentro il sito. Se il sito non può scrivere i propri file, non può nemmeno aggiornarsi da solo. L’aggiornamento forzato arriva, bussa, e non entra: senza un errore, senza un avviso, senza che nessuno se ne accorga. Nel frattempo il pannello mostra un avviso di aggiornamento disponibile che nessuno legge, perché nel pannello non ci entra nessuno per settimane.

La lezione, in una riga: se blocchi la scrittura dei file, e devi farlo, l’aggiornamento diventa un lavoro che qualcuno deve fare a mano. Se non sai chi è quel qualcuno, non lo fa nessuno.

La guida: controlla il tuo sito in cinque minuti

Nessun terminale, nessun comando. Solo il pannello di WordPress.

Passo 1. Che versione hai?

Bacheca → Aggiornamenti. In fondo alla pagina, in piccolo, c’è la versione.

Se sei sul ramo	La versione sicura è
7.0	7.0.2 o superiore
6.9	6.9.5 o superiore
6.8	6.8.6 o superiore
precedente alla 6.8	non sei interessato da questo problema

Se il numero che leggi è più basso, sei esposto adesso, mentre leggi. Non fra un mese.

Passo 2. Guarda chi sono i tuoi amministratori

Utenti → Tutti gli utenti, poi clicca su Amministratore in cima alla lista.

Devi riconoscere ogni singolo nome. Non “mi pare di sì”: riconoscerlo.

1. Nomi che iniziano per w2s_: è la firma dello strumento, nessun margine di dubbio.
2. Email che finiscono per @wp2shell.local.
3. Il numero accanto a “Amministratore” in cima alla lista: se è più alto di quello che ti aspetti, qualcuno è di troppo, anche se a colpo d’occhio i nomi sembrano tutti normali.
4. Nomi plausibili che però non ti dicono niente: i camuffati usano l’email del tuo dominio e sembrano colleghi.

Passo 3. Se trovi qualcosa, nell’ordine giusto

L’ordine conta. Se cancelli l’account e basta, domani mattina ne trovi un altro: la porta è rimasta aperta.

1. Aggiorna WordPress alla versione sana della tabella. Prima di ogni altra cosa.
2. Cancella gli account che non riconosci.
3. Cambia la password di tutti gli amministratori veri, uno per uno.
4. Controlla Utenti → Profilo → Password per le applicazioni: sono chiavi d’accesso separate, che continuano a funzionare anche dopo che hai cambiato la password. Cancella quelle che non hai creato tu, spesso hanno nomi dall’aria tecnica e servono a pubblicare spam.
5. Guarda i plugin installati, non solo quelli attivi. Se ne trovi uno che non hai messo tu, il problema è più grande di questo articolo e ti serve qualcuno che guardi il server.

Passo 4. Il controllo che vale per sempre

Metti in agenda un promemoria mensile: guarda la lista amministratori del sito.

Trenta secondi. È la cosa più efficace che puoi fare da solo, perché funziona anche quando l’attacco è invisibile, e wp2shell lo è per costruzione: non altera i file, non lascia tracce, non fa scattare notifiche. L’unica cosa che non può nascondere è il risultato: c’è un amministratore in più.

Vigila sugli effetti, non sui metodi. I metodi cambiano ogni mese. Gli effetti no.

Per chi ha accesso ai registri del server

Se hai un tecnico, o sei tu il tecnico, questa è la parte che vale la lettura.

Quando si mette un blocco davanti a un attacco, i registri si riempiono di richieste respinte, codice 403, e quella distesa di rifiuti dà una sensazione confortante di muro che regge. È fuorviante: i rifiuti dicono solo che qualcuno sta provando, non che qualcuno fallisce.

Il codice da cercare, per questo attacco, è 207. Non è un errore: è la risposta di chi ha eseguito quello che gli è stato chiesto. Una sola riga 207 vale più di mille 403.

E c’è un motivo per cui i blocchi messi in fretta non tengono. Se il filtro guarda l’indirizzo della richiesta, si aggira cambiando l’indirizzo: per esempio spostando il comando dentro il corpo della richiesta, dove il filtro non guarda e WordPress invece legge lo stesso. Un blocco va messo dove la richiesta viene capita, non dove viene scritta. E dopo averlo messo, va riprovato l’attacco per vedere con i propri occhi che la risposta è cambiata. Non “dovrebbe essere chiuso”: chiuso.

Le due lezioni, una accanto all’altra

Un sito compromesso può sembrare perfetto. Quell’imprenditore apriva il suo sito ogni giorno e vedeva la home aziendale, mentre Google vedeva un sito di scommesse turche. Per tre anni. Il fatto che “si veda bene” non dice assolutamente niente.

Non basta più non commettere errori. Puoi non avere plugin, avere password lunghe, non aver mai scaricato un tema pirata, e restare comunque esposto, perché il difetto è nel motore, non in quello che ci hai montato sopra.

Quello che resta, in mezzo alle due, è una cosa sola: qualcuno deve guardare. Regolarmente, e sapendo cosa cercare.

Perché te lo raccontiamo

Perché un sito non è finito quando è online.

Noi facciamo siti in tre giorni lavorativi, a 500 euro più IVA, tutto incluso. Ma un sito veloce e bello che dopo sei mesi ha dentro un amministratore che non conosci non è un sito bello: è un problema con un bel carattere tipografico.

La cura di un sito è fatta di cose noiose e regolari: aggiornare quando esce la patch, contare gli amministratori, controllare che i backup si riaprano davvero. Nessuna di queste cose si vede. Tutte si notano quando mancano.

Se il tuo sito è su WordPress e non sai chi lo aggiorna, adesso lo sai: non lo aggiorna nessuno.