Il 7 luglio 2026 la CISA statunitense ha aggiunto quattro vulnerabilità al proprio catalogo Known Exploited Vulnerabilities (KEV), la lista delle falle di cui è documentato lo sfruttamento attivo in attacchi reali. Due di esse colpiscono i page builder di Joomla, i componenti che permettono di costruire le pagine di un sito trascinando blocchi grafici senza scrivere codice. Entrambe hanno il punteggio massimo — CVSS 10.0 — e consentono a un attaccante non autenticato di prendere il controllo del server. Per le agenzie federali americane il termine per correggerle era fissato al 10 luglio, ma il messaggio riguarda chiunque gestisca un sito Joomla, in qualunque Paese.

Come funzionano le due falle

La prima, CVE-2026-48908, riguarda SP Page Builder di JoomShaper, uno dei componenti più diffusi dell'ecosistema Joomla, e affligge tutte le versioni fino alla 6.6.1 inclusa. Il problema è un endpoint di caricamento — la funzione che gestisce l'upload delle icone personalizzate — che accetta un file senza richiedere alcun login e senza verificare il tipo di file. In pratica un attaccante può inviare un file PHP malevolo (una webshell) in una cartella servita dal web e poi eseguirlo, ottenendo il controllo remoto del sito. La correzione è arrivata con la versione 6.6.2.

La seconda, CVE-2026-56290, colpisce Page Builder CK di Joomlack, vulnerabile nelle versioni fino alla 3.5.10 inclusa. Anche qui il meccanismo è un caricamento di file arbitrario non autenticato: uno degli endpoint del front-end accetta l'upload lasciando persino scegliere all'attaccante la cartella di destinazione. L'unica barriera è un token anti-CSRF che, però, chiunque può leggere direttamente dalle pagine pubbliche del sito. Non esiste alcun controllo su chi sia l'utente o su cosa gli sia consentito fare. La versione che risolve il problema è la 3.6.0, rilasciata il 27 giugno.

In entrambi i casi il risultato è lo stesso: esecuzione di codice remoto con pieno controllo del server. I ricercatori che monitorano l'ecosistema Joomla hanno osservato, già dalla fine di giugno, tentativi di sfruttamento con creazione di account Super Administrator nascosti, installazione di backdoor PHP — veri e propri gestori di file — nelle cartelle dei componenti e accesso ai file di configurazione con le credenziali del database.

Cosa significa per le aziende italiane

Joomla è tutt'altro che marginale in Italia: lo usano moltissime PMI, associazioni, studi professionali, piccoli enti locali e siti di e-commerce, spesso costruiti anni fa da agenzie web e poi lasciati con manutenzione minima. E i page builder come SP Page Builder e Page Builder CK sono tra le estensioni più installate proprio perché permettono di aggiornare i contenuti senza toccare il codice. È questa combinazione — grande diffusione e scarsa manutenzione — a rendere le due falle particolarmente pericolose.

Il fatto che l'attacco sia non autenticato cambia radicalmente il profilo di rischio. Non serve rubare credenziali né superare un login: basta che il sito sia raggiungibile da Internet. Gli aggressori non prendono di mira il singolo bersaglio, ma effettuano scansioni di massa alla ricerca di installazioni vulnerabili, colpendo indistintamente il portale del comune e quello del negozio sotto casa. Chi non dispone di un team di sicurezza — cioè la stragrande maggioranza delle piccole realtà — è esattamente il bersaglio ideale.

Le conseguenze concrete vanno oltre la semplice defacement della home page. Un sito compromesso diventa un'arma nelle mani dell'attaccante: piattaforma per ospitare pagine di phishing, distribuire malware ai visitatori, minare criptovalute o attaccare altri siti. E se il sito gestisce dati personali — anagrafiche clienti, moduli di contatto, ordini — la webshell offre accesso diretto al database, trasformando l'incidente in una violazione di dati personali a tutti gli effetti.

Il quadro normativo

Quando un sito compromesso comporta l'accesso non autorizzato a dati personali, scatta l'obbligo GDPR di notifica al Garante entro 72 ore dalla scoperta e, nei casi di rischio elevato per gli interessati, la comunicazione alle persone coinvolte. Per i soggetti che rientrano nel perimetro NIS2 — recepita in Italia con il D.lgs. 138/2024 — la gestione tempestiva delle vulnerabilità note è un obbligo di sicurezza, con notifica al CSIRT Italia entro 24 ore per il pre-allarme e 72 ore per la notifica completa. Vale la pena ricordare che la responsabilità non si esaurisce nel fornitore del software: il titolare del sito resta responsabile della messa in sicurezza dei propri trattamenti.

Cosa fare subito

  • Aggiornare SP Page Builder alla 6.6.2 o successiva e Page Builder CK alla 3.6.0 o successiva: è la misura risolutiva.
  • Censire le estensioni Joomla installate e verificare quali page builder sono presenti, comprese le installazioni dimenticate su sottodomini e ambienti di test.
  • Se non è possibile aggiornare subito, mettere il sito dietro un WAF o metterlo temporaneamente offline finché la patch non è applicata.
  • Cercare le webshell nelle cartelle dei componenti (ad esempio quelle dei media e delle immagini) e nei percorsi usati per l'upload, alla ricerca di file PHP anomali.
  • Controllare gli account Super Administrator ed eliminare quelli sconosciuti o non riconducibili al personale.
  • Analizzare i log del web server in cerca di richieste POST verso gli endpoint di upload dei componenti.
  • Ruotare le credenziali dell'amministrazione Joomla e del database, e mantenere aggiornato il core di Joomla oltre alle estensioni.