A luglio 2026, su un sito WordPress ospitato su uno dei nostri server, sono comparsi di notte quattro utenti amministratori. Nessuno di noi li aveva creati, e nessuno del cliente.
Avevano nomi come w2s_ seguito da una fila di caratteri esadecimali, e indirizzi email che finivano in @wp2shell.local. Li aveva creati un attaccante per avere le chiavi del pannello.
Cosa è successo
Dai log, l'attacco arrivava da indirizzi IP di Google Cloud. L'attaccante ha provato a caricare un plugin «webshell», cioè una porta di servizio che permette di dare comandi al server dal browser. Il caricamento è fallito.
Lo stesso IP aveva sondato anche una dozzina di altri domini ospitati sullo stesso server. Andava a tappeto, alla ricerca di una porta aperta.
Negli stessi giorni arrivavano richieste a raffica all'endpoint REST wp-json/batch/v1, l'indirizzo di WordPress che permette di mandare più operazioni in una sola chiamata. Venivano da una ventina di IP diversi.
Cosa abbiamo fatto
- Via gli intrusi. Abbiamo cancellato i quattro utenti.
- Controllo su tutti i database del server. Abbiamo cercato quegli utenti sito per sito. Nessun altro sito li aveva.
- Chiavi nuove. Le chiavi segrete salvate nel sito le abbiamo considerate compromesse e rigenerate. Se l'attaccante le aveva lette, adesso non gli servono più.
- IP bloccati. Gli indirizzi coinvolti non entrano più.
- Regole per tutto il server. Abbiamo scritto regole ModSecurity, il firewall applicativo che gira sul server, valide per tutti i siti. Bloccano la firma dell'attacco, cioè il parametro
_w2s, e l'endpoint batch.
Su un singolo sito la stessa idea si esprime anche nel file .htaccess. Questa regola rifiuta con un errore 403 qualsiasi richiesta che contenga il parametro _w2s:
RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)_w2s= [NC]
RewriteRule ^ - [F,L]Sul server l'abbiamo messa a livello di ModSecurity. Così vale anche per i siti nati dopo, e per quelli dove nessuno si ricorderebbe di toccare l'.htaccess.
La lezione: si guarda tutto il server
Davanti a un sito bucato la tentazione è sistemare quel sito e chiudere la pratica. Ma lo stesso IP aveva provato una dozzina di domini sullo stesso server, e attacchi di questo genere girano in automatico su tutto quello che trovano.
Per questo, quando troviamo un'intrusione su un sito, il controllo lo facciamo su tutti i database e tutti i siti della macchina, e le contromisure le scriviamo per tutti. Se un sito era vulnerabile, il vicino potrebbe esserlo allo stesso modo.
Cosa può fare chi ha un sito WordPress
- Dare un'occhiata ogni tanto all'elenco degli amministratori. Un nome che non riconoscete è un allarme da prendere sul serio.
- Tenere aggiornati WordPress, temi e plugin, e togliere i plugin che non usate più.
- Chiedere a chi ospita il sito cosa succede agli altri siti sullo stesso server quando uno viene attaccato.
L'ultima domanda è quella che si fa meno spesso. Se la risposta è «sistemiamo il vostro», vale la pena insistere: su un server condiviso la sicurezza di ogni sito dipende anche da quella dei vicini.
