Una vulnerabilità non corretta in Grav CMS è stata usata per compromettere il sito di diffusione dati del gruppo ransomware Clop. Il caso riguarda criminali che colpiscono altri criminali, ma il messaggio per le aziende è molto concreto: anche un server “secondario”, con dati ritenuti poco importanti, può diventare un punto d’ingresso se resta su una versione non aggiornata.
Per una PMI o uno studio professionale, la lezione è semplice: non conta solo proteggere i sistemi più critici. Conta avere un processo costante di aggiornamento, controllo delle versioni e verifica dei servizi web esposti, perché una singola falla può bastare per aprire la porta a compromissioni, defacement e furti di file.
Che cosa è successo
Il 25 settembre 2026 BleepingComputer ha riportato che il gruppo ransomware Clop ha spostato il proprio sito di leak su un nuovo indirizzo Tor dopo che il precedente server era stato compromesso e alterato. Secondo quanto ricostruito, l’attacco sarebbe stato condotto da ShinyHunters, altro gruppo noto nell’ambiente cybercriminale.
L’incidente non si è limitato a una semplice sostituzione della home page. In un primo momento sarebbe stato caricato un piccolo file di testo; in seguito il sito sarebbe stato completamente deturpato con una pagina riconducibile a ShinyHunters. Lo stesso gruppo ha poi sostenuto di aver sottratto codice sorgente, plugin di Grav CMS, log del server e persino chiavi private usate dal servizio onion di Clop.
Clop ha confermato la compromissione e ha dichiarato di aver trasferito il sito su un nuovo indirizzo, mantenendo temporaneamente accessibile il vecchio dominio prima del ritiro definitivo. Ha inoltre negato rapporti o trattative con ShinyHunters e ha contestato il valore dei dati che gli avversari affermano di aver sottratto.
Al di là delle dichiarazioni dei gruppi coinvolti, il punto davvero rilevante è tecnico: il server compromesso usava una versione non completamente aggiornata di Grav CMS.
La vulnerabilità: perché era pericolosa
Secondo i dettagli confermati da Grav, il problema è una vulnerabilità di path traversal non autenticata, tracciata come CVE-2026-42608. In termini semplici, si tratta di un difetto che permetteva di manipolare il percorso dei file durante la gestione degli upload, sfruttando parametri inviati via POST.
Il meccanismo descritto da ShinyHunters e ritenuto corretto dagli sviluppatori di Grav riguardava la creazione di directory temporanee usate nei caricamenti dei form. Un identificatore fornito dal client non veniva validato in modo sufficiente prima di essere inserito nel percorso sul filesystem. Inserendo sequenze di traversal nelle richieste, un attaccante poteva far creare un percorso al di fuori della cartella prevista e scrivere file in posizioni diverse all’interno dell’installazione Grav.
Questo aspetto è cruciale per chi gestisce siti aziendali: non serve sempre rubare credenziali o bucare un firewall. A volte basta una funzione web esposta, apparentemente banale come un form, se il software sottostante ha un difetto non corretto.
Perché il caso Grav è interessante anche per chi non usa Grav
Molte aziende italiane non utilizzano Grav CMS. Eppure questa vicenda è istruttiva per almeno tre motivi.
Il primo è che il problema non era in un componente “esotico” inventato ad hoc dai criminali, ma in un CMS reale, utilizzato per siti web e portali. Le vulnerabilità nei sistemi di gestione contenuti restano una via d’accesso molto comune.
Il secondo è che la distinzione tra “sito vetrina” e “sistema importante” spesso inganna. Un server web può contenere pochi dati sensibili e tuttavia rappresentare un trampolino per attività successive: caricamento di file malevoli, persistenza, raccolta di informazioni tecniche, abuso del dominio o danno reputazionale.
Il terzo è che il rischio può dipendere dalla versione effettivamente in uso, non dal solo fatto che il prodotto esista o meno. In questo caso, Grav ha chiarito che la vulnerabilità era nel core del CMS, non nel plugin Form. Questo significa che concentrarsi sul plugin sbagliato avrebbe potuto far perdere tempo, mentre il vero elemento decisivo era la release del core.
Le versioni coinvolte e la correzione
ShinyHunters ha indicato che il server compromesso eseguiva Grav CMS 1.7.43. Grav ha confermato che i dettagli dell’exploit erano corretti e ha spiegato che la falla era stata già corretta nella linea 2.0, precisamente in Grav 2.0.0-beta.2, con advisory pubblicato il 27 aprile.
Il problema, però, era rimasto aperto per la linea 1.7. Gli sviluppatori hanno chiarito che le release 2.x erano già protette da mesi, mentre la correzione non era stata riportata retroattivamente sul ramo 1.7. Dopo la condivisione dei dettagli tecnici con Grav, il fix è stato retroportato e il 24 settembre 2026 è stata rilasciata la versione Grav 1.7.53.4, indicata come aggiornamento da installare per chi è ancora sul ramo 1.7.
La mitigazione introdotta consiste nella sanitizzazione dell’identificatore usato nel percorso temporaneo, accettando solo caratteri ammessi secondo una allowlist precisa. È un buon promemoria anche per chi sviluppa software interno: validare gli input non è un dettaglio, ma una misura fondamentale di sicurezza applicativa.
Cosa ci insegna questo episodio sui sistemi “non prioritari”
Un errore comune nelle aziende è pensare che alcuni sistemi possano aspettare perché “non contengono dati”. È una scorciatoia pericolosa.
Clop ha sostenuto che il server violato contenesse solo contenuti e nessuna attività finanziaria o dato operativo di valore. Anche se fosse vero, la compromissione c’è stata comunque. Questo basta per dimostrare che un sistema trascurato può essere usato per:
- pubblicare contenuti non autorizzati;
- ospitare file caricati da un attaccante;
- esporre informazioni tecniche utili ad altri attacchi;
- creare un danno d’immagine;
- segnalare all’esterno che il processo di aggiornamento non è sotto controllo.
Per un’azienda reale, il danno reputazionale può essere persino più costoso del danno tecnico. Un sito alterato, anche per poche ore, comunica al mercato scarsa affidabilità e mette in difficoltà clienti, fornitori e partner.
Cosa significa per la tua azienda
Se hai un sito aziendale, un’area riservata, un portale clienti o anche solo una landing page ospitata su un CMS, questo episodio suggerisce alcune azioni immediate.
La prima è fare un inventario delle versioni. Molte aziende non sanno con precisione quale CMS usano, quale versione del core sia installata e quali plugin siano attivi. Senza questa visibilità non esiste un vero patch management.
La seconda è distinguere tra aggiornato e realmente sicuro. Non basta sapere che “qualcuno ha fatto un update”. Serve verificare se il ramo software in uso riceve ancora correzioni e se eventuali fix pubblicati per versioni nuove siano stati resi disponibili anche per quelle più vecchie.
La terza è ridurre al minimo i componenti esposti. Form, pannelli di amministrazione, plugin poco usati e funzionalità legacy sono spesso superfici d’attacco sottovalutate. Se non servono, conviene disattivarli o rimuoverli.
La quarta è predisporre copie di sicurezza e procedure di ripristino rapide. In caso di alterazione del sito, la capacità di tornare online in tempi brevi fa la differenza. Un servizio di remote backup ben impostato aiuta a recuperare contenuti e configurazioni senza improvvisare nel momento peggiore.
La quinta è adottare un controllo continuativo dei sistemi client e server. Non serve aspettare un incidente per accorgersi che esistono software obsoleti o non supportati. Una gestione strutturata degli endpoint e degli asset IT, come quella offerta nei servizi di desktop IT management, aiuta a tenere sotto controllo aggiornamenti, esposizioni e anomalie operative.
Infine, vale la pena considerare un supporto specialistico sulla sicurezza informatica se in azienda non c’è una figura dedicata. Per una PMI, avere processi semplici ma costanti è spesso più efficace che inseguire soluzioni complesse solo dopo un problema.
Le tre domande che un responsabile d’ufficio dovrebbe farsi oggi
Di fronte a notizie come questa, la reazione più utile non è il tecnicismo ma il metodo. Chi gestisce l’operatività aziendale dovrebbe chiedersi:
- sappiamo quali applicazioni web sono pubblicate su Internet a nome dell’azienda?
- sappiamo chi aggiorna quei sistemi e con quale frequenza?
- sappiamo ripristinare sito e contenuti in tempi accettabili se qualcosa va storto?
Se anche una sola risposta è incerta, il problema non è Grav, né Clop, né il dark web. Il problema è la mancanza di governo dell’infrastruttura digitale.
Domande frequenti
Questa vulnerabilità riguarda solo chi usa Grav CMS?
Direttamente sì, nel caso specifico. Indirettamente riguarda tutte le aziende, perché mostra quanto sia rischioso lasciare online CMS e componenti non aggiornati.
Se il sito non contiene dati sensibili, posso rimandare gli aggiornamenti?
No. Anche un sito con soli contenuti pubblici può essere compromesso, alterato e usato come punto d’appoggio o fonte di danno reputazionale.
Cosa dovrei fare subito se ho un sito gestito da terzi?
Chiedi al fornitore quali versioni di CMS e plugin sono in uso, se ricevono aggiornamenti regolari, e come viene gestito il ripristino in caso di incidente.