Non attribuito (nessun attore o campagna nominati; disclosure di Phil Taylor / mySites.guru)critical
Quattro estensioni Joomla, un solo schema: l'ondata di upload non autenticati che pianta admin fantasma
In poche settimane quattro estensioni Joomla molto diffuse — SP Page Builder, iCagenda, PageBuilder CK e Balbooa Forms — sono finite nel catalogo CISA delle vulnerabilità sfruttate, tutte con lo stesso difetto: un endpoint raggiungibile senza login che accetta il caricamento di un file senza controllarne il tipo. Il risultato è una web shell PHP eseguita sul server. In almeno un caso il payload osservato pianta un Super Administrator nascosto con email @secure.local e semina backdoor "PHP File manager" in più cartelle. Nessun attore nominato: quello che colpisce è la ripetizione dello stesso errore in prodotti diversi.
Lo stesso bug, quattro volte in un mese
Tra la fine di giugno e i primi di luglio 2026 il catalogo CISA delle vulnerabilità note come sfruttate ha incassato, a pochi giorni di distanza, quattro estensioni Joomla diverse. SP Page Builder di JoomShaper e PageBuilder CK di Joomlack sono entrate il 7 luglio; iCagenda e Balbooa Forms il 10 luglio. Prodotti di vendor diversi, funzioni diverse — un page builder, un altro page builder, un calendario eventi, un costruttore di form — e un unico difetto sotto: un endpoint dell'estensione che accetta il caricamento di un file senza chiedere un login e senza controllare che tipo di file sia.
Il punteggio è identico e massimo: CVSS 9.8 nella scala 3.1, 10.0 nella 4.0, per tutte e quattro. La meccanica è la più classica e la più grave delle vulnerabilità web: un attaccante carica un file .php, ci naviga sopra con il browser, e il server lo esegue. Da lì il controllo è totale — rubare dati, deturpare pagine, piantare backdoor, usare il server per colpire altri siti.
Il caso meglio documentato: asset.uploadCustomIcon
Il più dettagliato dei quattro è SP Page Builder (CVE-2026-48908), una delle estensioni Joomla più installate al mondo. Il ricercatore Phil Taylor, che gestisce la piattaforma mySites.guru e ha tracciato l'attacco nei log reali, ha ricostruito il punto esatto: il controller espone un task chiamato asset.uploadCustomIcon, pensato per un compito amministrativo banale — caricare un'icona personalizzata — ma raggiungibile con una normale richiesta Joomla, senza alcun controllo di accesso e senza usare gli helper che Joomla mette a disposizione per validare i file caricati contro una lista di estensioni sicure.
Non serviva abilitare nulla, non serviva pubblicare una pagina: l'endpoint era attivo su qualunque installazione predefinita con il componente presente. La versione 6.6.2 chiude la falla aggiungendo il gate che sarebbe dovuto esistere fin dall'inizio — utente autenticato con permessi di amministrazione e token anti-CSRF valido, altrimenti 401/403. Tutte le versioni fino alla 6.6.1 restano vulnerabili.
- 01POST asset.uploadCustomIconrichiesta senza credenziali, file
.phpallegato - 02Scrittura sotto la web rootnessun controllo sul tipo di file
- 03GET sul file caricatoil server esegue la web shell
- 04Compromissione totaledati, backdoor, nuovi account amministrativi
Quello che l'attaccante lascia dietro
È qui che la storia smette di essere una CVE e diventa un problema di bonifica. Secondo l'analisi di mySites.guru, il payload osservato su SP Page Builder non si limita all'esecuzione una tantum: crea uno o più Super Administrator nascosti. I nomi visibili sono rassicuranti — "Web Editor", "Site Helper", "Admin Backup" — con username come webeditor67 o portaladmin51, ma il dettaglio che non cambia mai è l'email che finisce in @secure.local, un dominio inesistente che nessun account legittimo usa. Se su un sito Joomla compare un Super User con quell'indirizzo, quel sito è stato compromesso attraverso questo exploit.
In parallelo il dropper semina copie identiche di una backdoor — un pannello "PHP File manager ver 1.4" con file browser, console PHP e console SQL — in posti poco appariscenti: un .php sotto images/<random>/fonts/, e file chiamati users.php in cartelle come /media/com_admin/ e /media/regularlabs/. Le copie multiple servono alla persistenza: se ne trovi una e la cancelli, le altre restano.
C'è anche una trappola difensiva concreta che mySites.guru segnala: un WAF configurato per l'ondata JCE di quest'anno può non fermare questa. È un vettore con una firma di richiesta diversa, e regole tarate su com_jce sono state viste restituire 403 sull'exploit JCE mentre lasciavano passare asset.uploadCustomIcon con un 200. Il blocco per firma protegge da ciò che gli è stato descritto, e da nient'altro.
Cosa è verificato e cosa no
Va detto con precisione. Non c'è attribuzione: nessun attore nominato, nessuna campagna con un nome. Il catalogo KEV riporta l'uso in campagne ransomware come "Unknown" per tutte e quattro. Che dietro le quattro estensioni ci sia un unico gruppo o più attori che riusano la stessa classe di bug non è stabilito: la cosa certa è il pattern — endpoint AJAX o di form che salta il proprio controllo di autorizzazione — che è una delle vie più comuni con cui i siti Joomla vengono bucati per colpa di codice di terze parti.
Il dettaglio operativo del payload (gli account @secure.local, i percorsi delle backdoor) proviene dalla ricostruzione di mySites.guru su siti realmente compromessi da SP Page Builder; per le altre tre CVE la fonte primaria è l'ingresso in KEV e la scheda NVD, che confermano lo sfruttamento attivo e la classe di difetto ma non dettagliano lo stesso payload. Gli ID ATT&CK in testa — T1190, T1505.003, T1136.001 — non sono copiati da un advisory: sono una mappatura ragionata di ciò che la catena consente (raggiungere un'app esposta, installare una web shell, creare un account), non un dato di fonte primaria.
Cosa si fa, e subito
La remediation è aggiornare, su ogni sito, all'ultima versione: SP Page Builder 6.6.2, iCagenda 4.0.8, PageBuilder CK 3.6.0, e la release corretta di Balbooa Forms. Ma aggiornare chiude la porta d'ingresso, non caccia chi è già dentro: un sito patchato con un Super User fantasma sopra è ancora completamente compromesso. Per ogni sito che ha avuto una di queste estensioni in versione vulnerabile, la caccia è concreta — controllare la lista utenti per Super Administrator con email @secure.local, cercare .php inattesi sotto images/<random>/fonts/ e file users.php con la firma "PHP File manager" in /media/. Se si trova qualcosa, il sito va trattato come violato: rimuovere l'admin e ogni copia della backdoor, ruotare password Joomla, credenziali del database e chiavi FTP/SSH, forzare il logout di tutte le sessioni. La lezione, più del singolo CVE, è che la sicurezza dei tuoi siti dipende da codice scritto da altri: il giorno in cui una falla così diventa pubblica devi sapere in minuti quali dei tuoi siti la eseguono, e chi era già dentro prima di te.
