CVE-2026-85097 : Bricksforge WordPress CVSS 10.0 — RCE sans authentification exploitée

Les faits

Le 7 octobre 2026, les équipes de Patchstack ont détecté les premières tentatives d'exploitation active de CVE-2026-85097, une vulnérabilité critique (CVSS 10.0) affectant le plugin WordPress Bricksforge dans toutes ses versions jusqu'à la 3.1.8.9 incluse. La première attaque a été enregistrée à 21h47 UTC, et en moins de 24 heures, 63 adresses IP sources distinctes avaient rejoint la campagne d'exploitation.

Bricksforge est un plugin d'extension du builder WordPress Bricks, utilisé principalement par les agences et développeurs WordPress pour créer des formulaires avancés, des animations et des composants dynamiques. Selon les données du dépôt officiel WordPress.org, Bricksforge compte plus de 40 000 installations actives, une surface d'exposition considérable pour une vulnérabilité de cette sévérité.

Techniquement, la faille réside dans le gestionnaire de soumission de formulaires du plugin. Lors du traitement d'un formulaire, Bricksforge accepte un paramètre temporaryFileUploads contenant une URL contrôlée par l'attaquant. Le plugin valide insuffisamment l'extension du fichier cible avant de l'enregistrer sur le serveur. La validation MIME initiale peut être contournée en soumettant un fichier polyglotte GIF/PHP : un fichier qui commence par les octets magiques d'un GIF valide (GIF89a) mais dont la suite contient du code PHP exécutable.

Le deuxième vecteur de contournement exploite l'endpoint AJAX non authentifié bricksforge_regenerate_nonce. Normalement, WordPress protège ses actions AJAX avec des nonces liés à la session de l'utilisateur connecté. Or Bricksforge expose cet endpoint sans vérification d'authentification, permettant à n'importe quel visiteur anonyme d'obtenir un nonce valide. L'attaquant peut alors soumettre le formulaire avec ce nonce, faire passer la validation de sécurité initiale, et forcer le plugin à renommer le fichier polyglotte avec une extension .php dans son répertoire de destination, rendant le code PHP exécutable via une requête HTTP directe.

La chaîne d'exploitation complète se déroule donc en trois étapes : (1) obtention d'un nonce valide via l'endpoint non authentifié, (2) soumission d'un formulaire avec un polyglotte GIF/PHP et spécification d'un chemin de destination avec extension .php, (3) exécution du webshell déposé via une requête GET ou POST ordinaire. Aucune interaction utilisateur, aucun compte, aucune connaissance préalable du site cible n'est requise — ce qui justifie pleinement le score CVSS 10.0.

The Hacker News et SecurityWeek ont confirmé l'existence d'un PoC public circulant sur des forums spécialisés dès le 8 octobre 2026, soit moins de 24 heures après le début de l'exploitation. Ce PoC a mécaniquement élargi le bassin d'attaquants potentiels au-delà des acteurs sophistiqués, intégrant des scripts kiddies et des botnet operators capables de scanner à grande échelle.

Patchstack a publié un correctif virtuel (virtual patching) dans ses règles de pare-feu applicatif le 7 octobre 2026, simultanément à la notification de l'éditeur. La version 3.1.8.10 de Bricksforge, intégrant le correctif officiel, a été publiée le 9 octobre 2026. Entre la détection de l'exploitation et la disponibilité du patch officiel, une fenêtre de 48 heures s'est donc ouverte pendant laquelle les sites non protégés par un WAF étaient entièrement exposés.

Les indicateurs de compromission (IOC) publiés par Patchstack incluent des tentatives de création de fichiers avec l'extension .php dans les répertoires temporaires de WordPress (/wp-content/uploads/), des requêtes POST vers wp-admin/admin-ajax.php avec l'action bricksforge_regenerate_nonce, et des signatures de fichiers commençant par GIF89a suivies de balises PHP. La surveillance de ces patterns dans les logs Apache/Nginx permet de détecter une exploitation réussie ou tentée.

Impact et exposition

Toute installation WordPress avec Bricksforge <= 3.1.8.9 est exposée, indépendamment de la configuration des rôles utilisateurs ou des plugins de sécurité additionnels (sauf WAF avec règles spécifiques). Un attaquant réussissant l'exploitation obtient une exécution de code PHP avec les droits du processus web, lui permettant de lire tous les fichiers accessibles (wp-config.php, clés API, identifiants base de données), de déposer des backdoors persistantes, et d'utiliser le serveur comme pivot dans l'hébergeur. Les agences web gérant de multiples sites WordPress sur hébergement mutualisé sont particulièrement exposées si l'isolation des processus PHP est insuffisante.

Recommandations

• Immédiat : mettre à jour Bricksforge vers la version 3.1.8.10 via le tableau de bord WordPress ou via WP-CLI (wp plugin update bricksforge).
• Vérification de compromission : inspecter les logs d'accès web pour des requêtes POST vers admin-ajax.php?action=bricksforge_regenerate_nonce depuis des IP inconnues, et scanner /wp-content/uploads/ pour des fichiers .php non légitimes.
• WAF : déployer ou vérifier les règles de filtrage applicatif (Cloudflare, ModSecurity, NinjaFirewall) couvrant les uploads de fichiers polyglots.
• Hébergeurs mutualisés : vérifier l'isolation des processus PHP entre les sites et activer la journalisation des créations de fichiers dans les répertoires web.