Référencée CVE-2026-61511 (rien que ça), elle touche les versions 6.2.1 et antérieures, ainsi que la branche 6.1.6 et en dessous, et a été disclosed le 27 juillet 2026 par un chercheur travaillant avec SSD Secure Disclosure. Pour nous, la communauté PHP, c'est le genre de news qui fait grincer des dents: du legacy qui refait surface, avec un eval planqué au milieu, comme un fantôme qu'on croyait avoir exorcisé depuis l'époque de PHP 4.
Mais c'est quoi ce eval maléfique?
Le vice se niche dans vB5_Template_Runtime::runMaths](/articles/faille-critique-dans-vbulletin-execution/), fichier /includes/vb5/template/runtime.php. Le code applique bien une regex pour filtrer l'expression mathématique passée au moteur — sauf que (attention, piège de débutant!) ladite regex laisse passer les chiffres, les parenthèses, les points, les opérateurs arithmétiques… et même XOR. Autant de briques qui suffisent largement à monter des techniques d'obfuscation PHP et à reconstruire des callables sans [aucun caractère alphabétique! Du sandbox bypass à l'ancienne, façon puzzle qu'on résout en deux cafés.
L'exploitation ne réclame aucun compte admin, et c'est bien ça le game changer. Un endpoint de rendu de template exposé publiquement, et hop, on passe. SSD Secure Disclosure a identifié la route ajax/render/[template] comme chemin critique — et le template pagenav comme exemple parfait: son paramètre pagenav[pagenumber] (assigné à pagenav.currentpage) finit dans une expression {vb:math} qui transite par runMaths, puis par eval. Bref, de l'entrée utilisateur jusqu'à l'exécution, sans la moindre pause.
Pourquoi on devrait s'en soucier sans avoir de vBulletin?
Soyons honnêtes deux secondes: combien d'entre nous n'ont jamais touché à un vBulletin, ni à un moteur de templates legacy? Et pourtant, ce RCE coche des cases qui parlent à toute la communauté. D'abord, le pattern « eval de template » est un anti-pattern qu'on retrouve dans des moteurs maison, des builders de PDF, des systèmes de mailing… et même (chut, on ne nommera personne) dans certains frameworks internes qu'on préfère oublier. Ensuite, le scénario d'exploitation est un grand classique: endpoint public, paramètre numérique balancé dans une expression, et paf — commandes OS, web shell, vol de base, pivot latéral.
Vous maintenez encore du vBulletin (et il en reste, croyez-en notre veille)? C'est l'heure du patch en urgence, sans délai. La solution: passage à la 6.2.2, ou application des patchs sur les branches 6.2.1, 6.2.0 et 6.1.6. En attendant, un WAF ou une règle reverse-proxy qui bloque l'accès aux endpoints de rendu de templates peut servir de pansement — solution temporaire, pas guérison.
On fouille les logs: par où on commence?
Trois signaux à traquer en priorité dans vos journaux web et applicatifs: des POST inhabituels vers ajax/render/pagenav, des valeurs pagenav[pagenumber] exotiques (longues, signées, ou juste bizarres), et des processus PHP enfants suspects. Pensez aussi aux fichiers fraîchement créés et aux connexions sortantes depuis le serveur — typiques d'un web shell qui vient d'être posé.
Si vous suspectez une compromission, partez du principe que l'hôte est totalement compromis: rotation des credentials stockés sur le forum, chasse aux mécanismes de persistance, audit des accès adjacents. Le classique, mais qu'on oublie vite sous la panique.
Vous en pensez quoi, vous? On continue à faire confiance à nos moteurs de templates maison, ou on migre tout vers du Twig/Blade bien typé? Le débat est ouvert dans les commentaires!