Un’importante vulnerabilità di sicurezza è stata scoperta nel software per forum vBulletin (versioni dalla 5.0.0 alla 5.7.5 e dalla 6.0.0 alla 6.0.3). Questa vulnerabilità consente ad aggressori privi di account sul forum di eseguire codice dannoso sul server che ospita il forum. Ciò può portare al completo controllo del server, con potenziale esposizione di dati sensibili, deturpazione del sito o utilizzo del server per ulteriori attacchi. Il problema è particolarmente rilevante per i forum che eseguono versioni recenti di PHP (dalla 8.1 in poi) e risulta essere attivamente sfruttato secondo le segnalazioni.
| Prodotto | VBulletin |
| Data | 2025-06-02 16:14:45 |
| Informazioni | Fix Available, Active Exploitation |
Riassunto tecnico
Le versioni di vBulletin dalla 5.0.0 alla 5.7.5 e dalla 6.0.0 alla 6.0.3 sono vulnerabili a una falla di tipo Remote Code Execution (RCE) non autenticata. La causa principale risiede in un controllo di autorizzazione inadeguato combinato con l’uso improprio della Reflection API di PHP, che interessa in particolare l’endpoint ajax/api/ad/replaceAdTemplate.
La vulnerabilità, identificata come CVE-2025-48827, consente a utenti non autenticati di richiamare metodi protetti del controller API quando il software è eseguito su PHP 8.1 o superiore. Questo perché a partire da PHP 8.1 il comportamento della reflection è cambiato, consentendo potenzialmente di bypassare i controlli d’accesso previsti in determinate condizioni.
Gli aggressori possono sfruttare questa vulnerabilità inviando una richiesta POST opportunamente costruita al percorso / con il parametro routestring impostato a ajax/api/ad/replaceAdTemplate. In tale richiesta, è possibile iniettare nel parametro template un tag template malevolo di vBulletin, come <vb:if condition='" ... "'>, che può contenere codice PHP arbitrario, ad esempio passthru($_POST['cmd']) oppure, come visto nel template Nuclei fornito, var_dump("some_random_string") come proof-of-concept.
Una seconda richiesta POST, anch’essa a / con routestring impostato a ajax/render/ad_<location> (dove <location> corrisponde a quello usato nella prima richiesta), attiva il rendering del template iniettato, eseguendone quindi il codice PHP con i privilegi dell’utente del server web.
L’exploit sfrutta quindi un processo suddiviso in due fasi: prima per iniettare il codice template malevolo tramite replaceAdTemplate e poi per renderizzarlo ed eseguirlo tramite ajax/render/ad_<location>. Ciò consente a un attaccante non autenticato di ottenere l’esecuzione di codice remoto.
Viene inoltre menzionata la vulnerabilità CVE-2025-48828, probabilmente riferita a un aspetto strettamente correlato di questa catena di vulnerabilità o al problema più ampio dell’invocazione di metodi protetti.
Raccomandazioni
- Aggiornare immediatamente: aggiornare vBulletin alla versione 6.0.4 o successiva. Se si utilizza vBulletin 5.x, applicare tutte le patch di sicurezza disponibili, in particolare quelle che affrontano l’invocazione dei metodi protetti del controller e la messa in sicurezza della funzionalità di sostituzione degli annunci.
- Web Application Firewall (WAF): implementare regole WAF per bloccare le richieste che tentano di sfruttare questa vulnerabilità. Queste regole potrebbero:
- Ispezionare il parametro
routestringper identificare valori sospetti comeajax/api/ad/replaceAdTemplateoajax/render/ad_. - Rilevare tag template di vBulletin (
<vb:if>, ecc.) contenenti funzioni PHP di esecuzione (es.passthru,shell_exec,system,eval,exec,var_dump) all’interno del parametrotemplatedella chiamatareplaceAdTemplate. - Bloccare l’invocazione diretta di metodi API protetti se il WAF è in grado di identificare tali pattern.
- Ispezionare il parametro
- Considerazioni sulla versione di PHP: sebbene la possibilità di sfruttare la vulnerabilità sia maggiore su PHP 8.1+, i difetti logici sottostanti possono esistere anche su versioni precedenti di PHP. Non fare affidamento sull’uso di una versione più vecchia di PHP come mitigazione completa.
- Analisi dei log del server: monitorare i log di accesso del server web e i log applicativi per richieste che corrispondano al pattern dell’exploit (richieste POST a
/conroutestring=ajax/api/ad/replaceAdTemplateoroutestring=ajax/render/ad_) per rilevare eventuali tentativi di compromissione.