Caso reale anonimizzato · luglio 2026

Il sintomo

Le 23:40. Il monitoraggio segnala che la homepage dello studio risponde HTTP 500. Non era un rallentamento e non era un timeout. Pagina bianca, errore server, sito irraggiungibile.

Uno studio legale non è un sito qualsiasi. Nelle pagine ci sono nomi, riferimenti a pratiche, moduli di contatto. Dietro, un'area riservata con documenti. Prima ancora di rimettere online la homepage, quella notte c'era da sapere se qualcuno avesse letto quello che non doveva.

Da dove veniva il buco

Il core girava sulla versione 7.0.0. Uscita da poche settimane, e già bucata: CVE-2026-63030, la falla che gli attaccanti hanno battezzato WP2Shell. Permette a una richiesta non autenticata di raggiungere un endpoint della REST API e scrivere un file PHP dentro la webroot. In pratica, una webshell caricata da fuori, senza password, senza login.

Non era un attacco mirato allo studio. Era una scansione di massa: bot che setacciano internet a caccia di siti fermi a 7.0.0, e appena ne trovano uno piantano lo stesso payload. Lo studio è finito nella rete a strascico. Il sito era in linea da mesi senza un aggiornamento, e quella settimana è bastato.

La notte, ora per ora

23:40 → 00:10 · Diagnosi del fatal

Un 500 con corpo vuoto non dice niente da solo. WordPress si ferma a metà del caricamento e Apache restituisce l'errore senza spiegarlo. Per vederci dentro, il sistema sostituisce index.php con un wrapper che forza display_errors e aggancia un register_shutdown_function: così l'errore fatale esce nel corpo della risposta invece di sparire nel nulla.

Alla richiesta successiva compare il messaggio: un file in wp-includes/ restituiva Cannot redeclare. Non era un plugin rotto: qualcuno aveva messo le mani sul cuore di WordPress.

00:10 → 01:30 · La webshell e il core sporco

La scansione del filesystem trova il file caricato via WP2Shell: uno script PHP dal nome anonimo in una cartella degli upload, con dentro un blocco offuscato che legge i comandi da $_POST e li esegue. La classica backdoor: chi ha la chiave entra, chi passa non vede niente.

Insieme alla webshell, due file del core con byte aggiunti in coda — l'aggancio che l'attaccante usa per ricaricare il payload anche dopo una pulizia frettolosa. Il resto di wp-content risultava intatto: temi, plugin e caricamenti al loro posto, nessuna modifica recente sospetta.

01:30 → 02:45 · Reinstallazione del core pulito

Riparare i singoli file manomessi è tempo perso: non sai mai quanti ne hai mancati. Il sistema scarica wordpress.org/latest, estrae in una cartella temporanea e ricopia sopra wp-admin/ e wp-includes/ per intero, più i file di root del core.

Due cartelle restano fuori dalla copia, sempre: wp-content/ e wp-config.php. Sono la parte del cliente — contenuti, configurazione, chiave del database. Sovrascriverle vorrebbe dire distruggere il sito per pulirlo.

02:45 → 03:30 · Aggiornamento e rimozione della backdoor

Il core torna pulito, ma resta alla 7.0.0: la stessa porta aperta di prima. Il sistema porta WordPress a 7.0.2, la release che chiude WP2Shell, poi elimina la webshell negli upload e i due file di aggancio. Ogni file rimosso finisce prima in un backup con marca temporale, mai una cancellazione secca.

03:30 → 04:15 · Rotazione delle chiavi e logout forzato

Qui viene la parte che quasi tutti saltano. La webshell è girata per ore: chi l'ha piantata può aver rubato i cookie di sessione degli utenti connessi. Cambiare le password non basta — una sessione aperta resta valida.

Il sistema riscrive le otto chiavi salt in wp-config.php con valori freschi presi da api.wordpress.org. Ogni sessione attiva salta di colpo: chiunque fosse dentro con un cookie rubato viene sbattuto fuori. È il taglio netto al dirottamento di sessione, quello che rende inutile la refurtiva.

04:15 → 05:00 · Verifica finale

Un 200 non prova che il sito funzioni. Il sistema controlla il corpo della homepage: titolo presente, markup del tema, peso oltre la soglia minima, zero tracce di Fatal error. Poi passa in rassegna i link interni della home e verifica che rispondano. L'area riservata carica, il modulo di contatto risponde, le pagine delle pratiche si aprono. Sito recuperato.

I dati dei clienti

Per uno studio legale è la domanda che conta più del sito online. Il controllo sugli accessi al database e sulle richieste registrate durante la finestra dell'attacco non ha trovato query di esportazione né traffico anomalo verso l'esterno: la webshell era stata piantata da poche ore e la scansione di massa cercava un punto d'appoggio, non un bottino specifico. La rotazione delle chiavi e l'espulsione di ogni sessione hanno chiuso la finestra prima che diventasse un problema. E i documenti riservati, quelli che contavano più di tutto, non si erano mossi.

La lezione

WP2Shell non ha scelto lo studio. Ha trovato una versione vecchia e ha bussato. La differenza tra un sito bonificato in una notte e un disastro da migliaia di euro sta in due cose: un aggiornamento fatto in tempo, e un occhio che veglia alle 23:40 anche quando in ufficio non c'è nessuno.

WPSonar tiene aggiornato il core, sorveglia il sito e, quando qualcosa cede, interviene senza aspettare che sia il proprietario ad accorgersene la mattina dopo.