CVE-2026-61511 : vBulletin RCE pré-auth CVSS 9.8, PoC public

Les faits

Le 27 juillet 2026, la publication d'un exploit fonctionnel pour CVE-2026-61511 sur plusieurs plateformes de divulgation, dont SSD Secure Disclosure et Karma(In)Security, a fait basculer cette faille dans la catégorie des menaces activement exploitables. Signalée le 25 juin 2026 puis corrigée le 1er juillet par vBulletin, la vulnérabilité affecte l'un des moteurs de forums les plus déployés au monde et permet une exécution de code à distance sans authentification préalable, d'où un score CVSS de 9,8. Concrètement, un attaquant non authentifié peut prendre le contrôle du serveur hébergeant le forum, exfiltrer la base d'utilisateurs, y implanter une porte dérobée ou pivoter vers le reste de l'infrastructure. Pour les administrateurs n'ayant pas encore appliqué le correctif, la fenêtre de remédiation est désormais close : chaque instance exposée doit être considérée comme compromise jusqu'à preuve du contraire.

La faille réside dans le fichier /includes/vb5/template/runtime.php, au sein de la méthode vB5_Template_Runtime::runMaths(). Cette fonction traite les expressions mathématiques utilisées par le tag de template {vb:math}. Avant de passer une valeur à la fonction PHP native eval(), elle applique un filtre par expression régulière censé n'autoriser que les chiffres, parenthèses, opérateurs arithmétiques et l'opérateur XOR. Cette approche de liste blanche était perçue comme suffisamment restrictive pour prévenir toute injection de code.

Le chercheur à l'origine de la découverte — travaillant avec SSD Secure Disclosure — a démontré que ce filtre est contournable via une technique connue sous le nom de phpfuck, une variante de jsfuck adaptée à PHP. Cette méthode permet de construire des appels de fonctions PHP et une logique exécutable arbitraire en utilisant uniquement des caractères autorisés par le filtre : chiffres, parenthèses et opérateurs. En exploitant l'opérateur XOR entre des valeurs numériques converties en caractères ASCII, il est possible de reconstituer des noms de fonctions dangereuses comme system() ou passthru() et d'en forcer l'exécution via eval().

Le vecteur d'exploitation est particulièrement dangereux car il est entièrement non authentifié. Le template de pagination pagenav de vBulletin lit une valeur pagenav[pagenumber] directement depuis la requête HTTP, l'assigne à une variable de template, puis l'intègre dans une expression mathématique qui atteint finalement runMaths(). Un attaquant n'a qu'à envoyer une requête POST spécialement forgée à la route publique ajax/render/pagenav pour déclencher l'évaluation de son code. Aucun compte, aucun cookie, aucun jeton CSRF n'est requis.

Selon le référencement NVD/NIST, CVE-2026-61511 affecte toutes les versions de vBulletin dans les branches 5.x jusqu'à 5.7.5 inclus et dans les branches 6.x jusqu'à 6.2.1 inclus. vBulletin est un logiciel de forum commercial très répandu, utilisé par des dizaines de milliers de communautés en ligne, notamment dans les domaines du gaming, de l'automobile, du sport et des médias. La surface d'exposition potentielle est donc considérable.

La chronologie de la divulgation est caractéristique d'une gestion responsable initialement bien maîtrisée : le chercheur a soumis la faille le 25 juin 2026 via SSD Secure Disclosure ; vBulletin a publié la version 6.2.2 corrigeant la vulnérabilité dès le 1er juillet 2026, soit six jours après le signalement. Cependant, la publication d'un PoC fonctionnel sur des plateformes publiques le 27 juillet — 26 jours après le patch — a radicalement changé le niveau de risque pour les instances non mises à jour.

D'après les analyses de BleepingComputer et The Hacker News, des tentatives de scanning automatisé ciblant la route ajax/render/pagenav ont été détectées dans les heures suivant la publication de l'exploit. La disponibilité d'un PoC fonctionnel abaisse drastiquement la barrière d'entrée pour les attaquants et génère typiquement une augmentation rapide des tentatives d'exploitation contre les serveurs vBulletin exposés sur Internet. L'outil de scan Nuclei de ProjectDiscovery dispose déjà d'un template permettant de détecter les instances vulnérables.

Il n'existe pas à ce jour de rapport confirmé d'exploitation en masse structurée par un acteur étatique ou un groupe de ransomware identifié, mais les scanners opportunistes sont actifs depuis la divulgation du PoC. Compte tenu de la nature de la faille — pre-auth, sans interaction utilisateur, vecteur réseau — et du score CVSS 9.8, le risque d'exploitation active à grande échelle dans les prochains jours est élevé selon les analyses de Karma(In)Security (référence KIS-2026-13) et LatestHackingNews.

Impact et exposition

Tout serveur vBulletin accessible sur Internet exécutant une version 5.x inférieure ou égale à 5.7.5 ou 6.x inférieure ou égale à 6.2.1 est directement exposé. L'exploitation ne requiert aucune condition préalable : pas de compte utilisateur, pas d'interaction de l'administrateur, pas de configuration spécifique autre que l'accès réseau à la route ajax/render/pagenav. En cas d'exploitation réussie, l'attaquant obtient une exécution de code PHP dans le contexte du processus serveur web, lui permettant de lire le fichier de configuration config.php, d'accéder aux identifiants de base de données, de voler les hash de mots de passe des membres, et potentiellement d'élever ses privilèges si le serveur est mal configuré.

Les forums vBulletin hébergent souvent des données sensibles : emails des membres, messages privés, historiques de paiement pour les abonnements premium. Une compromission réussie peut entraîner une violation de données massives soumise à notification RGPD, avec des obligations déclaratives envers la CNIL dans un délai de 72 heures. Pour les opérateurs de forums communautaires, l'impact réputationnel s'ajoute aux risques légaux et financiers.

Les instances hébergées en mode SaaS par vBulletin directement ne sont pas concernées par cette faille spécifique. Seules les installations auto-hébergées sont vulnérables. Il n'existe pas de condition d'exploitation particulière liée à la configuration réseau : dès lors que la route ajax/render/pagenav est joignable depuis Internet, ce qui est le cas dans une installation standard, l'exploitation est triviale.

Les pare-feux applicatifs peuvent constituer une couche de protection temporaire si le fournisseur a intégré une signature pour CVE-2026-61511, mais ne constituent pas un substitut au patch. Cloudflare et Imperva ont rapidement publié des règles de détection pour cette CVE selon les rapports de CyberSecurityNews et GBHackers.

Recommandations immédiates

• Mettre à jour immédiatement vers vBulletin 6.2.2 — advisory : vBulletin Security Advisory 2026-07-01 (Karma(In)Security KIS-2026-13, SSD Secure Disclosure)
• Si la mise à jour immédiate est impossible : configurer le WAF ou le pare-feu pour bloquer les requêtes POST vers /ajax/render/pagenav contenant des séquences XOR ou des expressions phpfuck
• Auditer les logs d'accès pour toute requête inhabituelle vers ajax/render/pagenav depuis des IP inconnues, particulièrement depuis le 27 juillet 2026
• Changer les identifiants de base de données et vérifier l'intégrité des fichiers de configuration si une compromission est suspectée
• Activer l'authentification à deux facteurs pour les comptes administrateurs vBulletin et surveiller les connexions d'administration inhabituelles