Se hai ricevuto un’email da parte mia che ti rimanda a questa pagina, è perché il tuo sito sembra utilizzare una versione di iCagenda (il com_icagenda di JoomliC, un’estensione di calendario eventi per il sistema di gestione dei contenuti Joomla) interessata da un problema di sicurezza noto. Questa pagina spiega di cosa si tratta, come verificare se ti riguarda e come risolverlo.

Questo avviso riguarda CVE-2026-48939, una falla critica, attivamente sfruttata, che consente il caricamento arbitrario di file senza autenticazione con conseguente esecuzione di codice remoto attraverso il modulo «Invia un evento» del front-end dell’estensione. È stata aggiunta al catalogo Known Exploited Vulnerabilities della Cybersecurity and Infrastructure Security Agency degli Stati Uniti il 10 luglio 2026.

Due condizioni, ed entrambe devono valere

Il tuo sito è interessato dal problema di esecuzione di codice remoto quando entrambe queste condizioni sono vere:

  1. iCagenda si trova sulla linea 4.0.x, con una versione inferiore alla 4.0.8 (cioè dalla 4.0.0 alla 4.0.7), e
  2. il nucleo di Joomla è inferiore alla 6.1.2.

Se iCagenda è alla 4.0.8 o successiva, non sei interessato. E se il nucleo di Joomla è alla 6.1.2 o successiva, non sei interessato nemmeno con una vecchia versione di iCagenda, perché è il nucleo stesso a bloccare il caricamento. Se questa è la situazione del tuo sito, puoi fermarti qui, salvo notare che aggiornare iCagenda resta comunque utile.

La seconda condizione è il punto in cui questa pagina non concorda con l’avviso dello stesso fornitore, secondo cui il problema riguarderebbe solo i siti che eseguono Joomla 6. In realtà riguarda anche i siti Joomla 4 e Joomla 5 pienamente aggiornati, e più sotto espongo le prove di questo, perché se segui il link vedrai il fornitore affermare il contrario.

Se sei su una versione interessata, aggiorna iCagenda e, poiché questa falla è stata sfruttata prima che esistesse una correzione, controlla anche il tuo sito alla ricerca di segni che qualcuno sia arrivato prima di te (vedi Se eri su una versione interessata più sotto).

Una nota per chi si trova sulla linea più vecchia 3.9.x. L’intervallo di CVE pubblicato include la 3.9.x, e il fornitore ha corretto anche quella linea, nella 3.9.15. Dalla mia stessa lettura e dai miei test, la linea 3.9.x utilizza per il caricamento un percorso di codice diverso e protetto, quindi l’esito di esecuzione di codice remoto non è raggiungibile lì: su Joomla 4 e 5 il caricamento è bloccato dal nucleo, e su Joomla 6 quel percorso di codice non esiste più affatto, quindi la funzionalità semplicemente genera un errore. Questo non è un motivo per ignorare l’aggiornamento. Le stesse release correggono un controllo di autorizzazione mancante che consente a un visitatore anonimo di inserire nel tuo sito un evento non approvato (e, su Joomla 4 e 5, insieme a esso un file di un tipo consentito). Gravità inferiore, ma comunque da correggere: aggiorna alla 3.9.15 o successiva. Nota anche che il fornitore fornisce patch di sicurezza per la linea 3.9.x solo fino al 13 ottobre 2026.

Questo messaggio è legittimo?

Sì. È un avviso di divulgazione responsabile, in buona fede, da parte di un ricercatore di sicurezza indipendente. Non ti chiedo denaro, password o accesso al tuo sito, e non ho tentato di entrarci, di caricare nulla o di sfruttare alcunché.

Ciò che ho letto sono stati due file pubblici che il tuo sito serve a chiunque li richieda: il manifesto del componente iCagenda all’indirizzo /administrator/components/com_icagenda/icagenda.xml, e il manifesto del nucleo di Joomla all’indirizzo /administrator/manifests/files/joomla.xml. Entrambi sono semplici file XML di versione, e sono gli stessi due file descritti in Come verificare le tue versioni più sotto, così puoi vedere esattamente ciò che ho visto io. Questo è tutto. In particolare non ho inviato il tuo modulo eventi, non ho caricato nulla, e non ho richiesto la cartella degli allegati del tuo sito. Quel percorso compare più avanti in questa pagina solo come un punto in cui tu puoi controllare sul tuo stesso sito. Nulla di questo controllo tocca i tuoi dati, la tua area di amministrazione o qualsiasi altra parte privata del tuo sito.

Se vuoi verificare chi sono, trovi i contatti in fondo a questa pagina e nella pagina Chi sono.

Perché è importante

iCagenda pubblica un calendario eventi sui siti Joomla. Una delle sue funzionalità consente a un visitatore di inviare un evento tramite un modulo front-end, allegando facoltativamente un file, che finisce in images/icagenda/frontend/attachments/.

Nelle versioni interessate, quell’invio viene accettato senza effettuare il login, e l’allegato viene scritto su disco senza alcun controllo sul tipo di file, mantenendo il nome e l’estensione scelti da chi lo invia. Questa combinazione consente a un aggressore di collocare sul tuo server un programma a sua scelta ed eseguirlo: esecuzione di codice remoto completa, senza bisogno di alcun account né di alcuna collaborazione da parte tua.

Non è necessario che nulla sia attivato perché questo si applichi. Il modulo non deve necessariamente essere pubblicato o visibile ai visitatori: nelle versioni interessate il controller che vi sta dietro accettava comunque l’invio.

Non si tratta di un rischio teorico. È valutata 9,8 su 10 da NVD (e 10,0 dall’autorità assegnante secondo il nuovo sistema di punteggio), ed è attivamente sfruttata. Il fornitore segnala che lo sfruttamento è iniziato il 15 giugno 2026 alle 08:00 UTC, prima che esistesse la correzione, e descrive gli attacchi come automatizzati. La CISA lo ha aggiunto al catalogo Known Exploited Vulnerabilities il 10 luglio 2026.

Descrivo tutto questo al livello di dettaglio di cui un proprietario di sito ha bisogno per agire, e non oltre. Non sto pubblicando i dettagli che permetterebbero a qualcuno di riprodurlo, e ti chiedo di non provarlo contro il tuo sito o quello di chiunque altro. Leggere i tuoi due numeri di versione, come descritto più sotto, ti dice tutto ciò di cui hai bisogno per decidere cosa fare.

Se la mia email citava questo problema, significa che le versioni dichiarate dal tuo sito lo collocano nell’intervallo interessato su entrambi i fronti. Non ho verificato se il tuo sito specifico sia sfruttabile o già compromesso.

Dove questa pagina differisce dall’avviso del fornitore

L’avviso del fornitore vale la pena di essere letto e lo trovi collegato più sotto. Hanno rilasciato una correzione rapidamente e le loro indicazioni sono valide. Ma una frase sull’ambito applicativo al suo interno non regge, e poiché è proprio la frase che indurrebbe la maggior parte di chi legge questa pagina a rilassarsi, preferisco mostrare il mio lavoro anziché limitarmi ad affermarlo. L’avviso dice:

I caricamenti di file non sicuri erano già bloccati per impostazione predefinita su tutte le versioni di Joomla precedenti a Joomla 6. Solo le installazioni di iCagenda su Joomla 6 (6.0.0-6.1.1) presentavano la vulnerabilità critica di caricamento.

Ecco cosa ho misurato, su installazioni isolate di mia proprietà. Nessun sito di terzi è stato coinvolto in alcun momento.

  • iCagenda 4.0.x esegue il caricamento tramite la classe del framework Joomla\Filesystem\File, che proviene dal pacchetto joomla/filesystem incluso nel nucleo di Joomla. Non utilizza la più vecchia classe Joomla CMS dello stesso nome, che è quella che ha sempre avuto un controllo sui file sicuri e che presumibilmente è quella a cui l’avviso fa riferimento.
  • Quel metodo del framework ha ottenuto il proprio controllo sui file sicuri (il parametro $allowUnsafe e il test isSafeFile) solo nella joomla/filesystem 4.2.0, che è la versione distribuita con Joomla 6.1.2.
  • Le versioni effettivamente incluse nelle release di Joomla che ho verificato: Joomla 4.4.14 distribuisce filesystem 2.0.2 (nessun controllo), Joomla 5.4.7 distribuisce 3.2.0 (nessun controllo), e Joomla 6.1.2 distribuisce 4.2.0 (controllo presente).

Quindi un sito Joomla 4 o Joomla 5 pienamente aggiornato che esegue iCagenda dalla 4.0.0 alla 4.0.7 è esposto, ed è per questo che questa pagina definisce la condizione su Joomla come “inferiore alla 6.1.2” anziché “solo Joomla 6”. Nulla nel record CVE pubblicato, nella scheda NVD o nel catalogo CISA delimita questo problema per versione di Joomla; la frase dell’avviso è l’unico punto in cui compare un simile limite.

Come verificare le tue versioni

Non devi credermi sulla parola per nessuno dei due numeri, e ce ne sono due da verificare.

La tua versione di iCagenda, dal file manifesto (senza bisogno di login): apri

tuodominio.it/administrator/components/com_icagenda/icagenda.xml

e leggi il suo elemento <version>. Questo è uno dei due file che ho letto.

La tua versione di iCagenda, dall’area di amministrazione:

  1. Accedi all’amministrazione di Joomla (di solito su tuodominio.it/administrator).
  2. Vai su Sistema poi Gestione poi Estensioni.
  3. Cerca iCagenda e annota la versione installata.

Fai attenzione a quale icagenda.xml leggi. Il pacchetto iCagenda include anche un plugin di ricerca incorporato con un manifesto dello stesso nome, che porta un proprio numero di versione non correlato. Solo il percorso del componente indicato sopra ti dice quale versione dell’estensione è in esecuzione.

La tua versione del nucleo di Joomla: nell’amministrazione, vai su Sistema poi Informazioni di sistema. Oppure leggi /administrator/manifests/files/joomla.xml e prendi il suo elemento <version>. Questo è l’altro file che ho letto.

Non c’è modo di stabilire la versione di iCagenda dal codice sorgente pubblico della tua pagina, e non dovresti provarci. Le risorse front-end dell’estensione portano l’hash dei media a livello di sito di Joomla anziché un numero di versione, e l’unico numero dall’aspetto di versione che compare effettivamente nel codice sorgente della pagina appartiene al bundle di risorse del modulo calendario (un numero basso come 1.0.4) e non ha nulla a che fare con il componente. Il file manifesto o la schermata dell’amministrazione sono l’unico controllo affidabile.

Poi applica la regola indicata all’inizio di questa pagina: la linea 4.0.x inferiore alla 4.0.8 e un nucleo inferiore alla 6.1.2 significa interessato.

Come aggiornare

Il percorso più sicuro è aggiornare tramite Joomla stesso, effettuando prima un backup:

  1. Fai un backup del tuo sito (file e database) prima di apportare modifiche. La maggior parte dei provider di hosting offre backup con un clic, oppure puoi usare un’estensione di backup per Joomla.
  2. Nell’amministrazione di Joomla, apri Estensioni poi Gestione poi Aggiornamento, e fai clic su Trova aggiornamenti. Se un aggiornamento di iCagenda è elencato, installalo da qui.
  3. Se lì non compare alcun aggiornamento, scarica la release attuale direttamente dal fornitore, JoomliC, e installala tramite Estensioni poi Installa.
  4. Quale versione installare: la 4.0.8 è la release che corregge questo problema, ma la release attuale al momento della stesura è la 4.0.11, e le release successive alla 4.0.8 aggiungono ulteriore protezione attorno alla stessa funzionalità, incluso il blocco dell’esecuzione di codice dalla cartella media di iCagenda. Vai alla 4.0.11 piuttosto che fermarti alla 4.0.8. Sulla linea più vecchia, vai alla 3.9.15 o successiva.
  5. In alternativa, aggiornare il nucleo di Joomla alla 6.1.2 o successiva chiude anch’esso questo specifico problema, ma non sostituisce l’aggiornamento dell’estensione: il controllo di autorizzazione mancante si trova nella stessa iCagenda e solo un aggiornamento di iCagenda lo corregge.
  6. Dopo l’aggiornamento, conferma il nuovo numero di versione seguendo i passaggi sopra, e verifica che il tuo calendario continui a essere visualizzato e che l’invio degli eventi funzioni ancora come previsto.

Già che ci sei, vale la pena confermare che Joomla stesso e le tue altre estensioni siano aggiornati, poiché lo stesso principio si applica a tutte.

Se eri su una versione interessata

Poiché questa falla è stata sfruttata prima che fosse disponibile una correzione, un sito che eseguiva una versione interessata non dovrebbe presumere che aggiornare sia sufficiente. Aggiornare chiude la porta, ma non ti dice se qualcuno ci fosse già passato. Vale la pena verificarlo con calma anziché temere il peggio: la maggior parte dei siti non troverà nulla. Nelle parole dello stesso fornitore:

L’aggiornamento chiude il punto di ingresso e protegge la funzionalità di allegato dei file, ma non ripulisce un sito già compromesso. […] Conserva una copia di eventuali file sospetti come prova, eliminali, cambia le tue password e credenziali di Joomla, e verifica l’intero sito, non solo la cartella iCagenda.

Ecco cosa tu (o il tuo webmaster) puoi cercare sul tuo sito:

  • File PHP sotto images/icagenda/frontend/attachments/. Quella cartella dovrebbe contenere solo allegati di eventi. Su un host Linux, il controllo è:

    find images/icagenda/frontend/attachments -name '*.php' -type f
  • Eventi anonimi non approvati fermi nella tua coda di moderazione, cosa che non ti aspetteresti se non hai mai aperto al pubblico l’invio di eventi.
  • Voci nei tuoi log di accesso da uno scanner che si identifica come icagenda-batch/1.0.

Dalla 4.0.8 in poi, iCagenda controlla anche autonomamente eventuali segni di compromissione e solleva un avviso dopo l’aggiornamento se ne trova. Il fornitore è chiaro sul fatto che l’assenza di tale avviso non è una garanzia, quindi si tratta di un segnale utile più che di un attestato di pulizia certa.

Se trovi uno qualsiasi di questi segnali, considera il sito compromesso: conserva copie dei file sospetti come prova e poi rimuovili, ruota tutte le credenziali (amministratore Joomla, database, FTP/SSH, pannello di hosting), rivedi i tuoi account utente Joomla e i gruppi a cui appartengono, e verifica l’intero sito, non solo la cartella iCagenda. Ripristinare da un backup effettuato prima del 15 giugno 2026 è spesso più sicuro che ripulire sul posto, perché una backdoor lasciata indietro può annullare la pulizia. Se la tua organizzazione dispone di un team di sicurezza IT o di un CERT nazionale, coinvolgili.

Voglio essere chiaro: non ho controllato il tuo sito per nessuno di questi indicatori, e non so se il tuo sito sia stato interessato. Questo elenco è qui perché tu possa controllare da solo.

Non ho un webmaster / sono bloccato

Se non sei tu a occuparti del sito, inoltra questa pagina a chi lo fa (il tuo sviluppatore web, la tua agenzia o il tuo provider di hosting). Riconosceranno rapidamente i passaggi sopra.

Se gestisci il sito da solo e ti blocchi, sono felice di aiutarti a indicarti la direzione giusta senza alcun costo. Contattami usando i dettagli qui sotto.

Contatti

Evan Harris, ricercatore di sicurezza

Mi metto in contatto su questioni come questa solo per aiutare gli operatori a mettere in sicurezza i loro siti. Se preferisci non essere più contattato, basta dirmelo e lo rispetterò.

Riferimenti

Avvisi ufficiali e tracciamento

Fornitore (JoomliC)