A pochi giorni dai due page builder finiti nel mirino, il CMS Joomla torna al centro dell'attenzione: la CISA statunitense ha aggiunto al proprio catalogo Known Exploited Vulnerabilities (KEV) altre due falle in estensioni molto diffuse — iCagenda e Balbooa Forms — entrambe con il punteggio massimo CVSS 10.0 e già sfruttate come zero-day, cioè prima ancora che esistesse una correzione. È il secondo episodio in pochi giorni con lo stesso schema, e non è una coincidenza.

I fatti

Le due vulnerabilità condividono la stessa dinamica: caricamento di file arbitrari da parte di un utente non autenticato, che si trasforma in esecuzione di codice PHP sul server.

  • CVE-2026-48939 colpisce iCagenda, l'estensione per la gestione del calendario eventi. La funzione di allegato dei file accetta upload senza controlli adeguati, permettendo il caricamento e l'esecuzione di codice PHP. Secondo le ricostruzioni è sfruttata in attacchi automatizzati dal 15 giugno 2026. JoomliC ha corretto il problema nelle versioni 4.0.8 e 3.9.15 (per il ramo 3.x).
  • CVE-2026-56291 riguarda Balbooa Forms, un diffuso costruttore di moduli. Fino alla versione 2.4.0 inclusa, la funzione di caricamento allegati lato frontend accettava un file da qualsiasi visitatore anonimo, senza login, senza token anti-CSRF e senza alcun controllo sul tipo di file: un attaccante poteva caricare una webshell PHP in una cartella pubblica ed eseguirla, ottenendo il controllo remoto del sito. La falla è stata scoperta da mySites.guru l'8 luglio 2026 in seguito a un attacco reale su un cliente ed è corretta nella versione 2.4.1.

Entrambe si sommano a un pattern già osservato: pochi giorni prima avevamo raccontato due falle CVSS 10 nei page builder di Joomla — SP Page Builder e Page Builder CK — con lo stesso identico difetto di fondo: un endpoint di upload che non verifica né chi carica né cosa. Non stiamo assistendo a episodi isolati, ma a una campagna sistematica che dà la caccia alle estensioni Joomla con caricamento file non protetto, sfruttandole con scansioni di massa automatizzate.

Cosa significa per le PMI, i comuni e le associazioni italiane

Qui sta il punto che rende la notizia particolarmente rilevante per l'Italia. iCagenda (calendario eventi) e Balbooa Forms (moduli di contatto e iscrizione) sono estensioni che si trovano ovunque nei siti di comuni, pro loco, scuole, parrocchie, associazioni e piccole imprese: proprio le realtà che hanno costruito il sito anni fa, girano su hosting condiviso e raramente dispongono di un presidio di sicurezza o di un processo di aggiornamento regolare. È il bersaglio perfetto per un attacco automatizzato: tanti siti, poco aggiornati, nessuno che controlla i log.

Le conseguenze di una webshell installata non si fermano al defacement. Un server compromesso viene tipicamente usato per rubare i dati raccolti dai moduli (nomi, email, a volte documenti allegati), per distribuire malware o spam a nome del sito legittimo, per ospitare pagine di phishing, o come testa di ponte verso altri siti presenti sullo stesso hosting. E se i moduli raccoglievano dati personali — come accade quasi sempre — una compromissione di questo tipo è a tutti gli effetti una violazione di dati personali.

Il contesto normativo

Per un ente pubblico o un'azienda, la sottrazione di dati personali tramite il sito impone di valutare la notifica al Garante entro 72 ore (art. 33 GDPR) e, in caso di rischio elevato, la comunicazione agli interessati (art. 34). Le pubbliche amministrazioni e i soggetti che rientrano nel perimetro NIS2 hanno inoltre obblighi di segnalazione degli incidenti al CSIRT Italia. Vale la pena ricordare che la responsabilità resta in capo al titolare del trattamento anche quando il sito è affidato a un fornitore esterno: la manutenzione di sicurezza va messa nero su bianco per contratto, non data per scontata.

Cosa fare subito

  • Aggiornare iCagenda alla 4.0.8 (o alla 3.9.15 per chi è sul ramo 3.x) e Balbooa Forms alla 2.4.1.
  • Cercare segni di compromissione: file PHP sospetti o creati di recente nelle cartelle di upload (ad esempio images/, media/, tmp/) e richieste POST anomale verso gli endpoint di caricamento nei log del web server.
  • Rimuovere le estensioni non utilizzate: ogni componente installato è superficie d'attacco in più, anche quando è disattivato.
  • Impedire l'esecuzione di PHP nelle cartelle di upload tramite configurazione del server (regole .htaccess o equivalenti su Nginx).
  • In caso di compromissione accertata: isolare il sito, ripristinare da un backup pulito antecedente all'attacco, ruotare tutte le credenziali (database, FTP, amministrazione) e avviare le eventuali notifiche.
  • Iscriversi ai bollettini di sicurezza — degli sviluppatori delle estensioni, del CSIRT Italia e dei CERT europei — per non scoprire in ritardo la prossima falla della serie.

Il messaggio di fondo è chiaro: nel 2026 un sito Joomla "che funziona" ma non aggiornato è un rischio concreto, e sono le estensioni — non il core del CMS — l'anello debole che gli attaccanti stanno prendendo di mira in modo sistematico.