CVE-2026-61511 : PoC public vBulletin pre-auth RCE via PHP eval — des milliers de forums exposés

Les faits

Le 27 juillet 2026, SSD Secure Disclosure a publié un avis de sécurité accompagné d'un code de preuve de concept interactif pour CVE-2026-61511, une vulnérabilité d'exécution de code à distance pré-authentifiée affectant le logiciel de forum vBulletin. La publication de ce PoC marque le passage d'une faille théoriquement corrigée à un outil d'exploitation directement utilisable, mettant en danger immédiat tous les forums vBulletin n'ayant pas encore appliqué le correctif disponible depuis le 1er juillet 2026.

La vulnérabilité a été découverte et signalée à vBulletin le 25 juin 2026 par les chercheurs de SSD Secure Disclosure. L'éditeur a réagi en publiant la version 6.2.2 le 1er juillet 2026, soit six jours après la notification initiale. Des correctifs de rétro-portage désignés "Patch Level 1" ont simultanément été publiés pour les versions 6.2.1, 6.2.0 et 6.1.6 ainsi que pour la branche 5.x jusqu'à la version 5.7.5.

Sur le plan technique, la faille réside dans le fichier /includes/vb5/template/runtime.php, précisément dans la méthode vB5_Template_Runtime::runMaths(). Cette méthode est appelée lors du rendu des templates vBulletin pour évaluer des expressions mathématiques définies dans les gabarits de page. La fonction passe directement l'input utilisateur à PHP eval() sans désinfection ni validation préalable. Un attaquant peut ainsi injecter du code PHP arbitraire dans une requête HTTP de rendu de template et obtenir une exécution de code sous l'identité du processus web — généralement www-data ou apache — avec accès complet au système de fichiers et à la base de données MySQL du forum.

Les professionnels de la sécurité reconnaîtront immédiatement ce schéma. CVE-2019-16759, la vulnérabilité vBulletin qui avait fait grand bruit en septembre 2019, exploitait un mécanisme quasi-identique : un appel non sécurisé à eval() dans un handler PHP différent. Sept ans plus tard, le même type de faille réapparaît dans le même logiciel, via une méthode différente mais avec la même conséquence — exécution de code PHP arbitraire sans authentification. Cette récurrence soulève des questions légitimes sur la maturité des pratiques de revue de code chez vBulletin et sur l'absence d'analyse de sécurité systématique du moteur de templates entre les versions majeures.

Le PoC publié par SSD Secure Disclosure contient une légère erreur intentionnelle — un caractère alphabétique substitué à un chiffre dans la charge utile — qui empêche son exécution directe sans modification. Selon SSD, cette pratique vise à compliquer l'utilisation par des acteurs peu qualifiés tout en permettant aux professionnels de la sécurité de comprendre le mécanisme. Dans les faits, cette protection est symbolique : l'erreur est triviale à corriger et les outils d'exploitation automatisés intègrent généralement leurs propres variantes de payload, indépendamment des PoC publiés.

Au 2 août 2026, CVE-2026-61511 n'a pas encore été ajoutée au catalogue Known Exploited Vulnerabilities (KEV) de la CISA, et aucune source publique n'a confirmé d'exploitation active dans la nature. Ce contexte ne doit pas induire une fausse sécurité : l'expérience des vulnérabilités précédentes sur vBulletin montre que l'exploitation de masse peut démarrer dans les heures suivant la publication d'un PoC, notamment via des scanners automatisés qui parcourent en permanence les forums exposés sur Internet.

L'ampleur du parc vBulletin potentiellement exposé est difficile à estimer avec précision. Historiquement, vBulletin a équipé des dizaines de milliers de forums : communautés gaming, forums spécialisés, communautés professionnelles et académiques. Beaucoup de ces installations sont maintenues par des administrateurs non professionnels qui ne suivent pas systématiquement les bulletins de sécurité de l'éditeur. Les scans Shodan et Censys révèlent régulièrement plusieurs milliers d'instances vBulletin accessibles publiquement, dont une proportion significative sur des versions datant de plusieurs trimestres.

La compromission d'un forum vBulletin via CVE-2026-61511 peut avoir des conséquences étendues : exfiltration complète de la base de données incluant adresses email, hachés de mots de passe, messages privés et données personnelles des membres. Sur les forums communautaires actifs, cela peut toucher des dizaines ou centaines de milliers d'utilisateurs. Dans les hébergements mutualisés, le serveur hébergeant le forum partage souvent des ressources avec d'autres sites, ouvrant la porte à un mouvement latéral sur l'infrastructure d'hébergement et une contamination croisée entre sites colocalisés.

Concernant la gestion de la divulgation, il convient de noter que vBulletin a démontré une réactivité satisfaisante sur ce dossier — six jours entre la notification et le patch est un délai court dans l'industrie. Cependant, la communication auprès des administrateurs de forums reste un défi structurel pour ce type de logiciel : contrairement aux solutions SaaS qui se mettent à jour automatiquement, les installations vBulletin on-premise nécessitent une action manuelle de l'administrateur, et nombreux sont ceux qui n'ont pas reçu ou pas lu l'avis de sécurité de l'éditeur daté du 1er juillet 2026.

Impact et exposition

CVE-2026-61511 est exploitable par n'importe quel acteur capable d'envoyer une requête HTTP vers un forum vBulletin. Le niveau de compétence requis est minimal — la faille est de type injection d'expression, bien documentée dans la littérature de sécurité offensive. L'exploitation peut être entièrement automatisée via des outils de scan et d'exploitation standardisés. Les forums exposés directement sur Internet sans WAF constituent les cibles les plus immédiates. Les hébergements mutualisés présentent un risque supplémentaire de contamination croisée entre sites colocalisés.

Recommandations

• Mettre à jour immédiatement : passer en version 6.2.2 ou appliquer le Patch Level 1 correspondant à votre version (disponible dans l'espace membres du site officiel vBulletin).
• Vérifier les logs d'accès : rechercher dans les logs Apache ou Nginx des requêtes inhabituelles vers le moteur de templates, notamment des paramètres contenant des fonctions PHP comme eval(), system(), exec() ou passthru().
• Auditer les fichiers modifiés : après mise à jour, vérifier qu'aucun webshell n'a été déposé en recherchant les fichiers PHP modifiés récemment (commande find avec critère -mtime) dans le répertoire d'installation vBulletin.
• Changer les credentials : si la mise à jour est différée, changer immédiatement les mots de passe du compte administrateur vBulletin et du compte MySQL associé.
• Activer un WAF : déployer des règles WAF bloquant les tentatives d'injection de code PHP dans les paramètres HTTP (ModSecurity avec le jeu de règles OWASP CRS couvre ce vecteur d'attaque).