Descrizione

SP Page Builder espone il task del controller asset.uploadCustomIcon per gestire il caricamento di un pacchetto di icone personalizzate:

Nelle versioni affette, questo task è raggiungibile senza autenticazione e senza un token anti-CSRF valido. Accetta un archivio ZIP (campo multipart custom_icon) e estrae il suo contenuto in una directory pubblicamente accessibile via web sotto la root del documento:

Poiché il caricamento è raggiungibile pre-autenticazione e i file estratti finiscono nella root web, un attaccante può scrivere file controllati in una posizione navigabile e raggiungerli via HTTP.

Ottenere l'esecuzione di codice nonostante il filtro sulle estensioni

Alcune build aggiungono un filtro lato server sui nomi dei file nell'archivio. Questo PoC aggira una comune implementazione con una catena a tre passaggi:

1. Blocklist sensibile alle maiuscole. Il filtro rifiuta .php minuscolo, .phtml, .phar, .php3–.php8, .pht, .inc, … ma non normalizza le maiuscole, quindi .PHP (e altre varianti con maiuscole miste) e .htaccess passano.
2. Gestore web server sensibile alle maiuscole. Un handler PHP predefinito di Apache (<FilesMatch "\.php$">) esegue solo .php minuscolo, quindi un .PHP caricato viene inizialmente servito come testo sorgente, non eseguito.
3. Override tramite .htaccess. Un .htaccess (che la blocklist non blocca) contenente AddType application/x-httpd-php .PHP viene depositato insieme al payload. Dove AllowOverride lo permette, questo registra .PHP come PHP e la shell caricata viene eseguita.

Il PoC impacchetta sempre una struttura valida di font icona (selection.json, style.css, fonts/<nome>.ttf) in modo che il caricamento sia accettato, quindi aggiunge la shell.

Adattivo — percorre una lista di estensioni eseguibili PHP (prima quelle con minore impronta), poi un fallback .htaccess, e si ferma al primo che esegue effettivamente codice:

1. Caricamenti diretti di singoli file — fonts/<shell>.<ext> per ciascuna di php, php3, php4, php5, php7, pht, phtml, phar, PHP, pHp, Php. Nessun .htaccess. Diversi filtri di SP Page Builder bloccano insiemi diversi, e diverse configurazioni Apache eseguono estensioni diverse — quindi questo trova qualsiasi combinazione che il target permette ed esegue.
2. fonts/.htaccess + fonts/<shell>.PHP (fallback) — solo se ogni tentativo diretto fallisce. Il .htaccess depositato (AddType … .PHP) forza l'esecuzione di un .PHP maiuscolo dove AllowOverride lo permette (è ciò di cui hanno bisogno gli host in stile 5.4.6).

Si ferma al primo metodo che esegue e stampa quale è atterrato. Ogni caricamento accettato viene tracciato, quindi --cleanup rimuove tutti (tentativi multipli possono lasciare directory scrivibili ma vuote).

A seconda della versione e dell'indurimento del server il risultato varia, e il PoC lo dichiara esplicitamente (vedi Risultati sotto): RCE completa, solo scrittura file (PHP disabilitato / AllowOverride None), corretto (solo admin), o non vulnerabile.

Requisiti

Utilizzo

Il target può essere fornito come argomento posizionale o tramite --url, con o senza schema.

Esempio (anonimizzato)

Risultati (e codici di uscita)

Il PoC comunica sempre il verdetto per il target:

Caratteristiche di sicurezza

• La shell web depositata è protetta da un token per-run casuale e restituisce 404 a chiunque non lo possieda — non è una backdoor aperta a tutti.
• --cleanup elimina la directory del payload creata.
• Le azioni predefinite sono innocue (id, un marker aritmetico).

Mitigazione

1. Aggiornare SP Page Builder alla versione 6.6.2 o successiva (aggiunge controlli di autenticazione, autorizzazione e CSRF al task di caricamento). Questa è la correzione principale.
2. Difesa in profondità sul web server:
   • Disabilitare l'esecuzione di PHP nelle directory di upload (/media/, /images/, /tmp) tramite il pool FPM o php_admin_flag engine off.
   • Impostare AllowOverride None su quelle directory in modo che un .htaccess depositato non possa riabilitare gli handler.
   • Utilizzare una whitelist case-insensitive per le estensioni di upload, mai una blacklist.
3. Verifica post-breach: cercare .php/.PHP inaspettati sotto media/.../iconfont/, nuovi account Super User e file manager piantati.

Riferimenti

• NVD — CVE-2026-48908
• CVE.org record — CVE-2026-48908
• Articolo tecnico — SP Page Builder uploadCustomIcon RCE (mySites.guru)
• Vendor — JoomShaper SP Page Builder (fix di sicurezza nella 6.6.2)
• SP Page Builder — Joomla Extensions Directory

Parole chiave

Joomla SP Page Builder exploit · com_sppagebuilder RCE non autenticata · CVE-2026-48908 PoC · asset.uploadCustomIcon upload file arbitrario · Joomla remote code execution · script exploit pentest.

DISCLAIMER

Questo software è pubblicato solo per scopi educativi e test di sicurezza autorizzati — ad esempio test di penetrazione per i quali si dispone di autorizzazione scritta, programmi bug-bounty che includono il target nello scope, competizioni CTF e propri sistemi di laboratorio.

Accedere, modificare o interrompere sistemi informatici senza autorizzazione è illegale nella maggior parte delle giurisdizioni. Sei l'unico e intero responsabile delle tue azioni. Usando, scaricando o distribuendo questo codice accetti che:

• lo utilizzerai solo contro sistemi di tua proprietà o per i quali hai esplicita e documentata autorizzazione al test;
• gli autori e i contributori non si assumono alcuna responsabilità per danni, perdita di dati, interruzione del servizio o conseguenze legali derivanti dall'uso o dall'abuso di questo codice;
• questo materiale è fornito "COSÌ COM'È", senza garanzie di alcun tipo, esplicite o implicite.

Se non accetti questi termini, non utilizzare questo software. Come per qualsiasi exploit/PoC pubblicamente disponibile, viene condiviso in buona fede per aiutare i difensori a rilevare, comprendere e correggere la vulnerabilità; ciò che ne fai è affar tuo.

Licenza

MIT — vedi LICENSE.