Comme le rapporte cyberpress.org, une vulnérabilité critique — estampillée CVE-2026-61511 — permet aujourd'hui à n'importe quel attaquant non authentifié d'exécuter du code PHP arbitraire sur les serveurs qui font encore tourner ce vénérable moteur de forums. Bref, on est en plein dans le scénario que personne ne veut voir se pointer un lundi matin: un RCE distant, sans même avoir besoin de cliquer sur un lien piégé.
Mais comment on en arrive là, sérieux?
Le drame se joue dans un fichier qu'on n'ouvre plus jamais, /includes/vb5/template/runtime.php, plus précisément dans la méthode vB5_Template_Runtime::runMaths. Cette fonction est censée évaluer les fameuses expressions du tag de template {vb:math} — pratique quand on veut faire des calculs dans un template. Sauf qu'avant de refiler la chaîne de caractères à PHP eval (oui, eval en prod, on a déjà vu plus sécurisé!), le code applique une regex censée filtrer tout ce qui n'est pas chiffre, parenthèse ou opérateur mathématique. Le problème? Le méchant opérateur XOR (^) passe à travers les mailles du filet. Et là, c'est le jackpot: grâce à la technique dite « PHPFuck » (cousine de JSFuck côté JS), on reconstruit n'importe quel nom de fonction — system, exec, tout ce que vous voulez — uniquement avec des caractères autorisés. Du coup, fini la petite expression innocente, on obtient un shell interactif avec les droits du serveur web. Élégant, non? (Enfin, élégant pour l'attaquant, évidemment.)
Et sans être admin, on fait comment?
C'est bien là que ça pique. Vous n'avez même pas besoin de compte, ni de cookie, ni de rien. Il suffit d'abuser de la route ajax/render/[template], qui ne vérifie pas l'authentification. Le template pagenav est l'exemple parfait: il balance directement le paramètre pagenav[pagenumber] dans une variable de template qui finit dans runMaths puis dans eval. Un POST bien ficelé sur ajax/render/pagenav, et l'attaquant récupère un shell. Cerise sur le gâteau: un PoC public est déjà en circulation, attribué au chercheur EgiX. Donc oui, on est en mode « prêt à l'emploi » côté exploitation, ce qui n'est jamais une bonne nouvelle pour les SOC qui pensaient avoir le temps.
Bon, et on fait quoi concrètement?
Déjà, on respire et on identifie ses instances vBulletin (versions 6.2.1 et antérieures, ainsi que 6.1.6 et antérieures sont concernées). vBulletin a publié un correctif complet en 6.2.2, ainsi que des patches ciblés pour les 6.2.1, 6.2.0 et 6.1.6 qui ne veulent pas migrer d'un coup. Si vous ne pouvez pas patcher dans l'immédiat, deux réflexes: bloquer ou restreindre l'accès à l'endpoint ajax/render/ côté serveur web ou WAF, et garder l'œil sur vos logs HTTP à la recherche de POST chelous sur ajax/render/pagenav ou routestring, avec des pagenav[pagenumber] remplis de parenthèses et de patterns XOR. Côté investigation, les chercheurs de SSD Secure Disclosure recommandent aussi de traquer les nouveaux fichiers PHP qui n'ont rien à faire là, les connexions sortantes suspectes, les processus enfants anormaux du serveur web, les templates modifiés, et les comptes admin que personne n'a créés. La vulnérabilité a été rapportée par un chercheur indépendant travaillant avec SSD Secure Disclosure et divulguée publiquement le 27 juillet 2026 — autant dire que la fenêtre d'exploitation est grande ouverte.
Allez, on l'espère que personne ne traîne encore un vBulletin oublié dans un coin d'un sous-domaine de 2012. Et sinon, c'est l'occasion rêvée de convaincre la direction qu'il est temps de migrer ce vieux forum vers une stack un peu plus moderne — parce que continuer à faire tourner un eval non sanitizé sur un logiciel legacy, en 2026, c'est un choix éditorial qu'il faut assumer!