vBulletin corrige une RCE pré-authentification critique — le PoC est public, la branche 5.x est abandonnée

Le 25 juin 2026, le chercheur indépendant Egidio Romano signalait une faille critique dans vBulletin via le programme SSD Secure Disclosure. Le 1ᵉʳ juillet, vBulletin 6.2.2 était publié. Le 28 juillet, le PoC devenait public. Le compte à rebours est terminé : toute instance vBulletin exposée sans le Patch Level 1 est une cible.

Une RCE par eval() qui contourne la sanitization

CVE-2026-61511 est une vulnérabilité de type remote code execution pré-authentification. Elle affecte les branches 5.x (jusqu’à 5.7.5) et 6.x (jusqu’à 6.2.1) du moteur de forum PHP propriétaire.

La cause racine se situe dans la fonction runMaths(), conçue pour évaluer des expressions mathématiques dans les templates. Cette fonction transmet l’entrée utilisateur à eval(), la fonction PHP d’exécution de code dynamique, sans nettoyage suffisant. En envoyant une requête forgée vers l’endpoint ajax/render/[template], un attaquant non authentifié peut faire transiter du code PHP arbitraire à travers un template vulnérable — notamment pagenav — et obtenir une exécution de commandes système sur le serveur.

La sanitization mise en place par vBulletin est contournée via la technique dite du « phpfuck », une méthode d’obfuscation qui échappe aux filtres en n’utilisant que des caractères valides dans un contexte d’expression PHP. SSD Secure Disclosure a publié une analyse technique complète ainsi qu’un exploit fonctionnel ciblant la route ajax/render/pagenav.

Le chercheur Egidio Romano n’en est pas à son premier coup d’éclat sur vBulletin. En mai 2025, deux failles critiques qu’il avait également découvertes avaient été massivement exploitées après la publication de PoC publics, avec des vagues de scans automatisés ciblant les instances non patchées.

L’historique de vBulletin, une répétition générale

CVE-2026-61511 n’est pas un incident isolé. Le code de vBulletin accumule une collection préoccupante de RCE critiques depuis plus d’une décennie, presque toutes ancrées dans le même schéma : une entrée utilisateur non nettoyée atteignant les primitives d’exécution dynamique de PHP.

En 2019, CVE-2019-16759 (CVSS 9.8) permettait à un attaquant non authentifié d’obtenir une RCE via la couche de routage ajax/api/. La chaîne d’exploitation tenait en une seule requête POST. En 2020, CVE-2020-17496 (CVSS 9.8) ciblait la même famille d’endpoints ajax/render/ via une injection de configuration de widget. En mai 2025, Romano avait déjà divulgué deux RCE pré-authentification supplémentaires via SSD, toutes deux exploitées activement dans les 48 heures suivant la publication.

Le dénominateur commun est le moteur de rendu de templates. L’architecture de vBulletin repose sur un système de templates PHP maison qui précède les pratiques modernes de sandboxing. Chaque template acceptant des paramètres contrôlés par l’utilisateur est un point d’entrée potentiel, et l’évaluateur d’expressions basé sur eval() transforme chaque erreur de sanitization en compromission complète du système.

Patch Level 1 pour la 6.x, abandon pour la 5.x

vBulletin 6.2.2, publié le 1ᵉʳ juillet 2026, corrige CVE-2026-61511. Des correctifs rétroportés sous l’appellation Patch Level 1 sont disponibles pour les versions 6.2.1, 6.2.0 et 6.1.6.

La situation est radicalement différente pour la branche 5.x. Wayne Luke, responsable du support technique de vBulletin, a déclaré sur les forums officiels du projet que les utilisateurs de versions antérieures à la 6.x doivent « mettre à niveau vers une version plus récente ». Traduction : aucun correctif ne sera publié pour la branche 5.x.

Cette décision place des milliers d’instances dans une position intenable. La branche 5.x, bien que vieillissante, reste déployée sur de nombreux forums actifs — communautés de jeux vidéo, portails de support technique, forums automobiles, boards de discussion spécialisés. Ces sites sont désormais structurellement vulnérables à une RCE sans authentification dont le PoC est public.

vBulletin, un géant endormi du web communautaire

Sorti en 2000, vBulletin a longtemps été le standard des forums en ligne. Il a équipé certaines des plus grandes communautés du web pendant deux décennies. Si le marché s’est fragmenté avec l’émergence de Discourse, XenForo, Flarum ou encore Discord, vBulletin conserve une empreinte significative.

Les chiffres exacts sont difficiles à obtenir — Internet Brands, propriétaire de vBulletin, ne publie pas de statistiques d’adoption —, mais des recherches Shodan pour les signatures vBulletin retournent encore plusieurs dizaines de milliers d’instances exposées. Parmi elles, une proportion non négligeable tourne sous la branche 5.x.

Or, une instance vBulletin compromise n’est pas qu’un forum défiguré. C’est une base de données d’utilisateurs — emails, mots de passe hashés, messages privés, historiques de connexion — qui tombe aux mains d’un attaquant. C’est aussi un serveur web qui peut servir de pivot vers le reste de l’infrastructure.

Détection et réponse immédiate

Pour les administrateurs concernés, la marche à suivre est binaire : patcher ou migrer. Il n’existe pas de contournement par configuration.

Si vous utilisez vBulletin 6.x

Appliquer le Patch Level 1 correspondant à votre version. Les packages sont disponibles sur le portail membre vBulletin. La mise à jour est triviale et ne nécessite pas de migration de base de données.

# Vérifier la version installée
grep "define('VB_VERSION'" /var/www/vbulletin/includes/version_vbulletin.php

# Après application du patch, vérifier que la version affiche Patch Level 1
grep "PATCH_LEVEL" /var/www/vbulletin/includes/version_vbulletin.php

Si vous utilisez vBulletin 5.x

Vous devez planifier une migration vers vBulletin 6.2.2+ ou une plateforme alternative. En attendant, les mesures d’atténuation suivantes réduisent la surface d’attaque sans l’éliminer :

• Placer l’administration et la zone membre derrière un VPN ou une authentification HTTP supplémentaire.
• Bloquer l’accès à l’endpoint /ajax/render/ au niveau du reverse proxy (nginx, Apache) — cette mesure brise certaines fonctionnalités de template mais neutralise le vecteur d’attaque connu.
• Activer un WAF avec une règle ciblant les requêtes POST vers ajax/render/ contenant des motifs PHP suspects (eval, system, exec, backticks).
• Surveiller les logs d’accès pour des requêtes vers /ajax/render/pagenav — une tentative d’exploitation laisse une signature HTTP identifiable.

# Exemple de règle nginx pour bloquer l'endpoint vulnérable
location ~ ^/ajax/render/ {
    deny all;
}

Ces mesures sont temporaires. Le PoC étant public, les scanners automatisés cibleront cet endpoint dans les jours qui viennent — si ce n’est déjà fait. La seule solution durable est la mise à niveau.

Verdict

CVE-2026-61511 coche toutes les cases de la faille critique ingérable : pré-authentification, RCE directe, PoC public, branche majeure non patchée. Le précédent de mai 2025 — où deux failles vBulletin similaires avaient déclenché des campagnes d’exploitation massive dans les 48 heures suivant la publication du PoC — ne laisse aucun doute sur ce qui arrive.

Si votre instance tourne sous vBulletin 6.x, appliquez le Patch Level 1 aujourd’hui. Si elle tourne sous vBulletin 5.x, vous n’avez pas de rustine à appliquer : vous avez une migration à exécuter. Priorisez-la avant que les scanners ne s’en chargent pour vous.

Références

• BleepingComputer — vBulletin fixes critical pre-auth RCE flaw with public exploit (28 juillet 2026)
• SSD Secure Disclosure — vBulletin Pre-Auth RCE — analyse technique et PoC
• vBulletin Forums — Announcement: vBulletin 6.2.2 Patch Level 1 Security Release (1ᵉʳ juillet 2026)
• Egidio Romano — CVE-2026-61511 technical write-up — analyse détaillée du chercheur
• BleepingComputer — vBulletin flaws exploited in the wild (mai 2025) — contexte des précédentes campagnes d’exploitation vBulletin