Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Fortinet 970x120px

RCE su vBulletin 5.x e 6.x sfruttando PHP 8.1: il nuovo exploit spiegato da EgiX

26 Maggio 2025 08:43

Il ricercatore di sicurezza Egidio Romano, noto anche come EgiX, ha recentemente pubblicato un’analisi approfondita su un exploit che colpisce le piattaforme vBulletin 5.x e 6.x, sfruttando una combinazione di due vulnerabilità (note come N-day): una novità introdotta in PHP 8.1+ relativa alla reflection API e una falla preesistente nel motore dei template di vBulletin.

L’attacco permette l’esecuzione di codice arbitrario da remoto (RCE) senza autenticazione.

L’origine dell’exploit: due vulnerabilità concatenate


Banner 600x600 V0.2

Cybersecurity Awareness efficace? Scopri BETTI RHC!
Sei un'azienda innovativa, che crede nella diffusione di concetti attraverso metodi "non convenzionali"? 
Red hot cyber ha sviluppato da diversi anni una Graphic Novel (giunta al sesto episodio), l'unica nel suo genere nel mondo, che consente di formare i dipendenti sulla sicurezza informatica attraverso la lettura di un fumetto.
Contattaci tramite WhatsApp al numero 375 593 1011 per saperne di più e richiedere informazioni oppure alla casella di posta graphicnovel@redhotcyber.com


Supporta Red Hot Cyber 

  1. Seguendo RHC su Google news
  2. Seguendo RHC su Telegram
  3. Seguendo RHC su WhatsApp
  4. Acquistando il fumetto sul Cybersecurity Awareness

Se ti piacciono le novità e gli articoli riportati su di Red Hot Cyber, iscriviti immediatamente alla newsletter settimanale per non perdere nessun articolo. La newsletter generalmente viene inviata ai nostri lettori ad inizio settimana, indicativamente di lunedì.

L’exploit descritto da Romano si basa sull’interazione tra due distinte vulnerabilità:

  1. Invocazione di metodi protected tramite Reflection su PHP 8.1+
    Con PHP 8.1, è possibile invocare metodi protetti e privati usando ad es. ReflectionMethod::invoke() senza dover richiamare esplicitamente setAccessible(true). In vBulletin, questa possibilità si traduce in un problema critico, poiché il framework API della piattaforma non implementa controlli adeguati sulla visibilità dei metodi.
  2. RCE attraverso “template injection” nel motore di rendering di vBulletin
    Il motore di template di vBulletin consente di creare interfacce dinamiche, dove il contenuto HTML può includere segnaposto o variabili che vengono valutate al volo prima della visualizzazione. Tuttavia, se non adeguatamente filtrati, questi template possono diventare un vettore di attacco.

Nel contesto dell’exploit analizzato da Egidio Romano (EgiX), la template injection consiste nel far sì che un contenuto controllato dall’utente venga inserito direttamente all’interno di un template e interpretato dal parser come codice da eseguire, invece che come semplice testo.

Dimostrazione tecnica: una doppia leva per ottenere RCE

Nel suo articolo, Romano dimostra come un attaccante possa sfruttare il routing dinamico delle API di vBulletin per invocare un metodo protected, nella fattispecie vB_Api_Ad::replaceAdTemplate(), normalmente inaccessibile. Questo metodo consente di creare un nuovo template.

Il passo successivo è sfruttare la vulnerabilità nel motore di template, facendo sì che i dati iniettati vengano interpretati come codice PHP. In questo modo, l’attaccante ottiene un’esecuzione remota di codice (RCE) sulla macchina che ospita vBulletin.

Riflessioni e considerazioni sulla sicurezza

Il lavoro di Egidio Romano evidenzia l’importanza di considerare l’impatto cumulativo delle vulnerabilità, specialmente quando si aggiornano componenti critici come il motore PHP. L’apparente innocua modifica al comportamento della reflection API in PHP 8.1 si è trasformata in una leva per accedere a metodi sensibili in vBulletin. Se a ciò si aggiunge l’esistenza di vecchie vulnerabilità non completamente mitigate nel sistema di template, si ottiene un vettore di attacco altamente efficace.

Romano invita gli sviluppatori di CMS e framework PHP a non affidarsi alla sola visibilità dei metodi (public, protected, private) come meccanismo di sicurezza, ma a introdurre controlli espliciti sulle autorizzazioni e sull’origine delle richieste.

Approfondimento

L’articolo completo con dettagli tecnici, codice PoC e analisi approfondita è disponibile sul blog ufficiale di EgiX: Don’t Call That ‘Protected’ Method: Dissecting an N-Day vBulletin RCE

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Manuel Roccon 300x300
Ho iniziato la mia carriera occuparmi nella ricerca e nell’implementazioni di soluzioni in campo ICT e nello sviluppo di applicazioni. Al fine di aggiungere aspetti di sicurezza in questi campi, da alcuni anni ho aggiunto competenze inerenti al ramo offensive security (OSCP), occupandomi anche di analisi di sicurezza e pentest in molte organizzazioni.
Aree di competenza: Ethical Hacking, Bug Hunting, Penetration Testing, Red Teaming, Security Research, Cybersecurity Communication