Sommario
Sono state identificate vulnerabilità critiche in due ecosistemi ben distinti: Linux, con Apport e systemd-coredump, e vBulletin, noto CMS per forum. Le prime possono portare all’esposizione non autorizzata di dati sensibili su sistemi Fedora, Red Hat e Ubuntu, mentre la seconda consente esecuzione di codice da remoto in installazioni vBulletin 5.x e 6.x, sfruttando un meccanismo riflessivo errato con PHP 8.1+. Entrambe le falle pongono gravi rischi in ambienti enterprise.
Vulnerabilità in Apport e systemd-coredump: fuga di dati da core dump
Le vulnerabilità CVE-2025-5054 e CVE-2025-4598 scoperte dal Qualys Threat Research Unit colpiscono Ubuntu (Apport) e Red Hat/Fedora (systemd-coredump). Entrambe si basano su una race condition che consente a un attaccante locale di accedere ai core dump generati da processi SUID, in particolare unix_chkpwd, ottenendo hash delle password da /etc/shadow.
systemd-coredump cattura i core dump al crash di un processo e li archivia per l’analisi. Se mal configurato, può includere dati sensibili. Lo stesso vale per Apport, il gestore di crash predefinito di Ubuntu, che raccoglie stack trace e dati diagnostici utili agli sviluppatori.
Le distribuzioni impattate includono Ubuntu 16.04–24.04, RHEL 9 e 10, e Fedora 40–41. Debian non è vulnerabile di default.
Un attaccante potrebbe indurre un crash su un programma privilegiato, ottenere un core dump, e da lì estrarre password, chiavi di cifratura o dati sensibili, compromettendo l’intero sistema.
Misure di mitigazione per Linux
La mitigazione più immediata è disattivare la possibilità per i programmi SUID di produrre core dump impostando:
bashCopiaModificaecho 0 > /proc/sys/fs/suid_dumpable
In alternativa, è possibile applicare i moduli di mitigazione automatica tramite la piattaforma Qualys TruRisk Eliminate, già integrata nei sistemi VMDR e agent-based. Questo approccio consente una mitigazione scalabile anche in assenza di patch immediate, senza impattare direttamente i binari vulnerabili.
vBulletin e l’invocazione non autorizzata di metodi protetti
Il CMS vBulletin, nelle versioni 5.x e 6.x, è vulnerabile a un attacco di tipo Remote Code Execution (RCE) che sfrutta una combinazione tra PHP 8.1, l’uso improprio delle Reflection API e l’assenza di controlli di visibilità su metodi protetti. L’origine della falla risiede nel sistema di routing delle API AJAX, che consente l’invocazione dinamica di metodi protetti tramite chiamate POST strutturate ad hoc.
PHP 8.1 consente, di default, l’invocazione di metodi protected con ReflectionMethod::invoke(), aggirando il controllo di accesso. In vBulletin, questo meccanismo consente a un attaccante non autenticato di invocare funzioni interne come replaceAdTemplate(), progettata per la gestione dei template pubblicitari, e iniettare codice PHP arbitrario all’interno dei template.
Catena di exploit su vBulletin: dalla riflessione all’esecuzione remota
L’exploit completo utilizza la funzione replaceAdTemplate per salvare un template contenente una chiamata a passthru($_POST["cmd"]), eseguendo comandi da remoto via POST. Il meccanismo si basa su vulnerabilità nei parser dei template di vBulletin, che non filtrano adeguatamente le condizioni all’interno di tag <vb:if>.
Un payload funzionante potrebbe avere la seguente struttura:
php-templateCopiaModifica<vb:if condition='"passthru"($_POST["cmd"])'></vb:if>
Tale codice viene compilato ed eseguito lato server, permettendo il controllo completo della macchina web. Il ricercatore EgiX ha dimostrato con prove di concetto l’efficacia dell’attacco su vBulletin 5.1.0, 5.7.5, 6.0.1 e 6.0.3.
Impatto e contromisure per le installazioni vBulletin
Le conseguenze di un RCE includono accesso completo al server, furto di database, inserimento di backdoor persistenti, e attacchi contro altri sistemi nella rete interna. La vulnerabilità è stata tracciata con i codici CVE-2025-48827 e CVE-2025-48828.
Le patch sono disponibili a partire dalla versione vBulletin 6.0.4, che corregge la riflessione impropria e limita l’esecuzione di codice nei template.
Le aziende dovrebbero:
- Aggiornare immediatamente a vBulletin ≥6.0.4
- Limitare l’accesso agli endpoint
/ajax/api/ - Monitorare template sospetti con
passthru,eval,systemoshell_exec - Disabilitare l’accesso a PHP Reflection ove possibile
I casi analizzati evidenziano quanto l’equilibrio tra flessibilità architetturale e controllo rigoroso dell’accesso sia fragile nei sistemi informatici. Le vulnerabilità nei core dump di Linux rappresentano una minaccia subdola ma estremamente concreta, che può compromettere la riservatezza dei dati anche senza privilegi elevati. D’altra parte, la falla in vBulletin conferma che l’uso delle Reflection API, se non affiancato da verifiche esplicite sulla visibilità e autenticazione, può trasformarsi in una porta spalancata per attacchi remoti.
In entrambi i contesti, le patch sono necessarie ma non sufficienti: è fondamentale che le architetture applicative vengano progettate considerando la possibilità di evoluzioni nei comportamenti del linguaggio (come nel caso di PHP 8.1) e di configurazioni di sistema non sicure per default (come per Apport e systemd-coredump). Solo una strategia di secure-by-design, unita a test proattivi di penetrazione e revisione continua del codice, può mitigare efficacemente il rischio.
