Il nostro sito era compromesso da settimane senza che nessuno se ne accorgesse.
NapoliBene.it girava su Joomla con il template Astroid. In superficie tutto funzionava normalmente — gli articoli venivano pubblicati, il sito rispondeva, i visitatori arrivavano. Quello che non vedevamo era una webshell installata nel filesystem: un accesso backdoor completo al server, al database, alle credenziali di sistema.
Il vettore d'attacco era un file SVG con payload offuscato in Base64. La pipeline di validazione di Astroid controllava solo l'estensione del file — SVG è considerato immagine, quindi accettato. Il contenuto non veniva analizzato. In pochi secondi, chi aveva caricato quel file aveva accesso completo alla nostra infrastruttura.
Perché Joomla + Astroid era vulnerabile
Il problema non era Joomla in sé. Era l'architettura di dipendenze. Con 20-30 componenti di terze parti installati — template, plugin, estensioni — ogni componente ha la sua pipeline di validazione, il suo ciclo di aggiornamenti, la sua superficie di attacco. Basta che uno di questi componenti gestisca l'upload dei file con una validazione superficiale — come nel caso di Astroid — e l'intero sistema è esposto.
Il tipo di attacco che ci ha colpito — RFI via SVG con encoding Base64 — è progettato esattamente per aggirare i sistemi che controllano solo l'estensione senza analizzare il contenuto reale del file.
La migrazione: zero downtime, WAF attivo
La decisione di migrare su un'architettura diversa era inevitabile. Non era una questione di "rinforzare" Joomla — il problema era strutturale. Aggiungere plugin di sicurezza sopra un sistema con dipendenze non controllate non risolve la vulnerabilità alla radice.
Abbiamo migrato su KeideaCMS, un CMS proprietario italiano senza plugin di terze parti. L'importatore nativo da Joomla ha trasferito articoli, categorie e media preservando gli URL con redirect 301. Il sito è rimasto online durante tutta la migrazione — nessuna interruzione editoriale, nessun minuto di downtime.
Quello che è cambiato strutturalmente: il FileUploadScanner di KeideaCMS analizza ogni file caricato con 6 livelli di controllo — PHP detection, webshell signatures, entropia Shannon, polyglot detection, verifica MIME type, blacklist estensioni. Il tipo di attacco che ci ha colpiti viene bloccato prima ancora di raggiungere il filesystem, indipendentemente dall'estensione del file.
Il WAF in produzione
Da quando il sito è su KeideaCMS, il firewall applicativo integrato monitora ogni richiesta in tempo reale con notifiche Telegram dirette alla redazione. Nelle prime settimane abbiamo visto in diretta cosa succede quando un sito viene attivamente scansionato: IP in blacklist bloccati, scanner bot che tentano path probing su percorsi WordPress inesistenti, richieste anomale intercettate prima di raggiungere l'applicazione.
Non sono attacchi eccezionali. Sono la normalità per qualsiasi sito con traffico reale. La differenza è averli visibili e bloccati invece di scoprirli — come ci è capitato — settimane dopo che il danno è già fatto.
Cosa abbiamo imparato
La sicurezza di un sito non dipende solo da quanto è aggiornato il CMS. Dipende dall'architettura: quante dipendenze esterne ha, quante superfici di attacco introduce ogni componente aggiuntivo, chi analizza realmente il contenuto dei file in upload invece di fidarsi dell'estensione.
Per chi gestisce una testata su Joomla o WordPress e non ha mai fatto un audit della superficie di attacco del proprio stack, il percorso che abbiamo seguito è documentato nel caso studio completo con gli screenshot reali del WAF in produzione e i dettagli tecnici della vulnerabilità.
