← Blog
JoomlaFile Upload RCEWeb ShellCISA KEV

Joomla Page Builder RCE: CVE-2026-48908 e la web shell che hai già

Due falle di file upload CVSS 10.0 nei page builder Joomla (CVE-2026-48908, CVE-2026-56290) sfruttate in massa per piazzare web shell e admin nascosti: la patch non li rimuove.

Zero Hunt Research··8 min di lettura

Il 7 luglio 2026 CISA ha aggiunto nello stesso giorno due falle di estensioni Joomla al catalogo Known Exploited Vulnerabilities, entrambe con punteggio CVSS 10.0, entrambe non autenticate, entrambe già sfruttate in the wild. CVE-2026-48908 riguarda SP Page Builder; CVE-2026-56290 riguarda PageBuilder CK. Sono estensioni diverse, di vendor diversi, ma condividono una sola classe di bug — un handler di upload senza autenticazione e senza controllo lato server sul tipo di file — e un solo esito: un attaccante remoto scrive un file PHP nel web root e lo esegue. La scadenza federale per la remediation era il 10 luglio. Se gestite un Joomla con una delle due estensioni e state leggendo dopo quella data, la domanda non è più "devo applicare la patch" — è "sto già ospitando una web shell".

Due page builder Joomla, un unico bug di file upload

I page builder sono componenti di layout drag-and-drop. Per permettere a un redattore di trascinare un'icona personalizzata su una pagina, SP Page Builder esponeva un task del controller, asset.uploadCustomIcon, raggiungibile a:

index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon

Il task serviva a un piccolo compito amministrativo. Secondo la disclosure di mySites.guru, "processava il file caricato senza alcun controllo di autenticazione e senza alcuna restrizione lato server sul tipo di file, e poi lo scriveva in una cartella sotto il web root" — /media/com_sppagebuilder/assets/iconfont/. Non invocava mai gli helper di upload nativi di Joomla che avrebbero rifiutato un'estensione .php. Così una richiesta HTTP anonima carica x.php, il server lo salva sotto un percorso raggiungibile via web, e l'attaccante lo richiama. Il file upload non autenticato diventa esecuzione di codice remoto non autenticata. CVE-2026-48908 colpisce SP Page Builder dalla 1.0.0 alla 6.6.1; la correzione è arrivata nella 6.6.2 il 14 giugno 2026.

PageBuilder CK è un codebase diverso con una falla di forma identica — CWE-284, controllo di accesso improprio su un percorso di upload, CVSS 10.0. Il manutentore, Phil Taylor, l'ha divulgata dopo che il suo stesso strumento aveva intercettato una web shell attiva:

"Entro poche ore dal rilascio della fix, il nostro strumento di analisi dei contenuti sospetti ha segnalato una web shell attiva su un sito Joomla collegato, piazzata proprio attraverso questa falla."

È il segnale. Non sono CVE teoriche in attesa di un proof-of-concept. Lo sfruttamento è iniziato prima che la maggior parte dei gestori avesse sentito il nome dell'estensione.

Cosa ottiene davvero l'attaccante da una RCE su page builder Joomla

L'esecuzione di codice su un web server è l'inizio dell'intrusione, non la fine. Le campagne osservate non si fermano alla shell — stabiliscono una persistenza che sopravvive alla stessa patch che state per applicare. Ricorrono due artefatti:

  • Un backdoor file-manager. Sulle vittime SP Page Builder, Censys e mySites riportano copie di un file manager PHP chiamato users.php depositate in /media/com_admin/, /media/regularlabs/ e images/<random>/fonts/. Sulle vittime PageBuilder CK la shell osservata è /media/com_pagebuilderck/gfonts/bhup.php, un uploader autonomo riconoscibile dalla stringa if( $_POST['_upl'] == "Upload" ).
  • Un Super Administrator nascosto. La campagna SP Page Builder crea un Super User Joomla fittizio la cui email termina sempre in @secure.local — un valore cablato che non cambia mai — con uno username composto da una parola-ruolo (webeditor, contentmgr, sysadmin, webmaster) più due cifre casuali.

È il secondo artefatto quello che i difensori sottovalutano. La web shell è l'impianto rumoroso; uno scanner o una reinstallazione spesso la intercettano. L'account admin fittizio è silenzioso e ha un aspetto legittimo. Vive nella tabella #__users, si autentica dal normale form di login e concede il controllo completo del CMS — contenuti, estensioni, gestione utenti — attraverso una funzione supportata. Cancellate la shell, aggiornate l'estensione, e l'attaccante rientra dalla porta principale con credenziali che ha coniato mentre eravate esposti.

È il senso del titolo di questo articolo. La finestra di esposizione si chiude quando applicate la patch. L'incidente no.

L'esposizione non è teorica

Censys ha osservato 194.793 proprietà web che caricavano il componente SP Page Builder al momento della disclosure — Apache (48%), nginx (23%), LiteSpeed (8%), con il 31% che annunciava PHP tramite header X-Powered-By. Joomla è il terzo CMS più diffuso sul web pubblico, e questi due page builder sono tra le sue estensioni commerciali più popolari. La superficie esposta è ampia, omogenea e banalmente fingerprintabile: il nome del componente vulnerabile compare nel sorgente della pagina. Per un avversario che scansiona in massa, è una lista di bersagli, non un progetto di ricerca. Per la falla SP Page Builder esiste un proof-of-concept pubblico su GitHub, che riduce a poche ore il divario tra disclosure e sfruttamento di massa.

La lezione strutturale si ripete in tutto l'ecosistema CMS: il progetto core è relativamente ben verificato, ma le estensioni di terze parti — page builder, form builder, gallerie — portano gli stessi privilegi di esecuzione con una frazione della revisione. Un endpoint di upload non autenticato in un'estensione popolare è una primitiva di RCE di massa migliore di gran parte dei bug di memory corruption, perché non richiede alcuno sviluppo di exploit. Richiede un comando curl.

Remediation

L'ancora resta stabile su #remediation di proposito — questo è il runbook, in ordine. Verificato contro gli advisory dei vendor per CVE-2026-48908 e CVE-2026-56290.

1. Sono vulnerabile?

Fate il fingerprint dell'estensione e della sua versione. Dal server:

# SP Page Builder è presente, e a quale versione?
find /var/www/html -name "sppagebuilder.xml" -exec grep -i '<version>' {} \;
# PageBuilder CK
find /var/www/html -name "pagebuilderck.xml" -exec grep -i '<version>' {} \;

Dall'esterno, il nome del componente trapela nel sorgente (com_sppagebuilder, com_pagebuilderck). Ogni sito che annuncia uno dei due è un candidato. Considerate l'endpoint di upload raggiungibile finché non avete provato il contrario.

2. Patch — versioni corrette esatte

Estensione Colpite Corretta Rilascio
SP Page Builder 1.0.0 – 6.6.1 6.6.2 14 giu 2026
PageBuilder CK (attuale) ≤ 3.5.10 3.6.0 27 giu 2026
PageBuilder CK (Joomla 4) < 3.4.10 3.4.10 27 giu 2026
PageBuilder CK (Joomla 3) < 3.1.1 3.1.1 27 giu 2026

Spubblicare o disabilitare il componente non è sufficiente — il controller vulnerabile può restare raggiungibile. Aggiornate il codice.

3. Non potete applicare la patch subito? Controlli compensativi

Guadagnate tempo a livello web mentre preparate l'update. Applicate un virtual patch sul percorso di upload e vietate l'esecuzione PHP nelle directory di upload:

# Blocca gli accessi non autenticati ai componenti vulnerabili (ModSecurity)
SecRule ARGS:option "@rx (com_sppagebuilder|com_pagebuilderck)" \
  "id:100048908,phase:1,chain,deny,status:403,log,\
   msg:'Blocked Joomla page-builder upload — CVE-2026-48908/56290'"
  SecRule REQUEST_METHOD "@streq POST" \
    "chain"
    SecRule REQUEST_COOKIES "!@rx [0-9a-f]{32}=" "t:none"

# Non eseguire mai PHP scritto nelle directory di upload
<DirectoryMatch "/var/www/html/(images|media|tmp)/">
  <FilesMatch "\.ph(p[0-9]?|t|tml)
quot;>
    Require all denied
  </FilesMatch>
</DirectoryMatch>

La seconda regola è quella di maggior valore: anche un upload riuscito è inerte se la directory non può eseguire PHP.

4. Cercate la compromissione (assumete la violazione)

La catena mappa su MITRE ATT&CK T1190 (Exploit Public-Facing Application) → T1505.003 (Web Shell) → T1136 (Create Account). Eseguite ogni controllo — la shell senza l'account, o l'account senza la shell, è comunque una compromissione completa.

cd /var/www/html

# T1505.003 — file PHP dove non dovrebbero mai esistere
find images/ media/ tmp/ -type f -name "*.ph*" 2>/dev/null
# Nomi file IOC noti di queste campagne
find . -type f \( -name "users.php" -o -name "bhup.php" \) \
  \( -path "*/media/com_admin/*" -o -path "*/media/regularlabs/*" \
     -o -path "*/media/com_pagebuilderck/*" -o -path "*/fonts/*" \) 2>/dev/null
# Firme di codice web-shell
grep -rlE '\$_(POST|REQUEST)\[.?_upl.?\]|eval\s*\(\s*(base64_decode|gzinflate)' \
  . --include="*.php" 2>/dev/null
# Qualsiasi PHP scritto nella finestra di esposizione
find . -name "*.php" -mtime -30 -not -path "*/cache/*" -not -path "*/tmp/*"

# T1136 — il Super Administrator fittizio (adattate il prefisso #__)
mysql -u root -p joomla_db -e "
  SELECT u.id,u.username,u.email,u.registerDate
  FROM jos_users u JOIN jos_user_usergroup_map m ON u.id=m.user_id
  WHERE m.group_id=8
    AND (u.email LIKE '%@secure.local' OR u.registerDate > '2026-06-01')
  ORDER BY u.registerDate DESC;"

L'email @secure.local e il parametro POST _upl sono i due IOC concreti specifici di queste campagne. Le ricerche per data-di-modifica e per firma di codice intercettano le varianti che hanno cambiato nome ai file.

5. Bonificate e verificate — dopo la patch

  1. Rimuovete ogni web shell e backdoor file-manager trovati al passo 4.
  2. Cancellate il Super Administrator fittizio, poi ruotate ogni credenziale admin residua e i segreti Joomla ($secret in configuration.php) e forzate il logout di tutte le sessioni (TRUNCATE jos_session).
  3. Ri-scansionate la tabella #__users e le directory di upload dopo che la patch è attiva — un risultato pulito prima della patch non significa nulla se l'attaccante è rientrato dal suo account.
  4. Confermate che l'endpoint ora rifiuti gli upload anonimi (fate un curl con un POST multipart innocuo verso asset.uploadCustomIcon e aspettatevi 403/401).

Un CVE chiuso non è un incidente chiuso finché non potete provare che sia l'impianto sia l'account non ci sono più.

Dove si colloca Zero Hunt

Il divario descritto in questo articolo — estensione patchata, impianto attivo, account admin silenzioso — è esattamente ciò che uno scanner di versione non può vedere. Uno scanner riporta "SP Page Builder 6.6.2, non vulnerabile" e prosegue; non ha alcun concetto del users.php depositato martedì scorso o dell'account [email protected] che si autentica dal form di login. Per questo Zero Hunt esegue una validazione in assumed-breach, non un controllo di versione.

Lo swarm di 10 agenti AI tratta un sito Joomla esposto come lo tratta l'avversario. L'agente Recon mappa i componenti esposti su internet e ne fa il fingerprint. L'agente Exploit ricostruisce la catena di file upload per ogni bersaglio con un payload generato localmente — non uno script preso da ExploitDB — così il test riflette quel deployment. Poi gli agenti Post-Exploit, Credential e Pivot fanno il lavoro che lo scanner salta: cercano la web shell piazzata, enumerano la tabella utenti per il Super Admin fittizio e provano se il CVE chiuso ha lasciato un punto d'appoggio attivo. Ogni finding è firmato ECDSA al momento della scrittura, così "abbiamo patchato e verificato pulito" è un artefatto verificabile per un auditor o un assicuratore, non un'affermazione. Le campagne change-triggered si rieseguono nel momento in cui un nuovo asset Joomla compare sul perimetro — proprio la finestra in cui queste due CVE vengono sfruttate.

C'è anche un testimone dal lato rete. Durante la finestra di esposizione, la scansione di massa per com_sppagebuilder e il beacon in uscita della web shell sono traffico che l'endpoint non registra mai — l'appliance non esegue alcun agente dentro il CMS. Il modello di AI Traffic Analysis di Zero Hunt, quattro teste di inferenza a 2,7+ Gbit/s sulla GPU dell'appliance, segnala i POST di upload anomali e il pattern di callback mentre l'attività è in corso, non nella revisione dei log del mattino dopo. Applicate la patch all'estensione — poi provate che nessuno sia entrato mentre era aperta.