Faille critique Bricksforge (CVSS 10) exploitée : vérifiez vos sites WordPress Bricks

Sécurité Lundi 19 octobre 2026

Une faille notée 10/10, exploitable sans compte utilisateur et déjà attaquée : c’est le cas de CVE-2026-85097, qui touche Bricksforge, une extension populaire du constructeur de pages WordPress Bricks. Si votre site utilise Bricks avec Bricksforge, il faut vérifier sa version dès aujourd’hui. Voici ce qu’il faut savoir et comment contrôler votre site.

Ce qui s’est passé

Patchstack a détecté les premières tentatives d’exploitation le 7 octobre 2026 à 21 h 47 UTC, environ neuf heures et demie avant la publication officielle de la CVE, le 8 octobre. La faille a été notée 10,0 par Patchstack et 9,8 par Wordfence (sévérité critique). Elle relève de la catégorie CWE-434 : téléversement de fichier sans restriction.

Versions vulnérables : Bricksforge jusqu’à la 3.1.8.9 incluse.
Versions corrigées : 3.1.8.10 pour la branche 3.x et 4.0.0 pour la branche 4. La 4.0.1 (8 octobre) corrige un problème lié, et la 4.0.2 (13 octobre) est la dernière version documentée.
Prérequis pour l’attaquant : aucun. Il n’a pas besoin de compte sur le site.

Les attaques observées venaient de 63 adresses IP différentes. Un groupe de 44 adresses a envoyé 56 requêtes identiques en quelques secondes : c’est le signe d’une exploitation automatisée, qui vise des sites au hasard et pas seulement des cibles choisies.

Comment fonctionne la faille

La faille se trouve dans le module de formulaires « Pro Forms ». Au moment de l’import, Bricksforge vérifie bien le type MIME du fichier. Mais à la soumission du formulaire, il fait confiance aux métadonnées envoyées par le navigateur, en particulier au champ url du paramètre temporaryFileUploads. L’attaque se déroule ainsi :

L’attaquant récupère un jeton (nonce) valide via un point d’accès AJAX public.
Il envoie une image GIF qui contient aussi du code PHP (un fichier « polyglotte »). Elle passe le contrôle MIME.
Il soumet un formulaire dont les métadonnées demandent d’écrire ce fichier sous un nom en .php, .phtml ou une variante (majuscules, encodage).
Il n’a plus qu’à appeler ce fichier pour exécuter son code sur le serveur.

Concrètement, un simple formulaire de contact permet de déposer une porte dérobée sur l’hébergement.

Suis-je concerné ? Vérifier et mettre à jour

Bricksforge est distribué commercialement, en dehors du répertoire WordPress.org. Le tableau de bord ne propose donc pas toujours la mise à jour : vérifiez la version vous-même. Avec WP-CLI :

# Version installée de Bricksforge
wp plugin list --name=bricksforge --fields=name,status,version

Si la version affichée est 3.1.8.9 ou inférieure, mettez à jour vers la dernière version disponible depuis votre compte Bricksforge. Si vous ne pouvez pas mettre à jour tout de suite, désactivez l’extension le temps de le faire :

wp plugin deactivate bricksforge

Chercher des traces de compromission

Mettre à jour ne supprime ni les fichiers ni les comptes créés lors d’une éventuelle intrusion. Si votre site était vulnérable après le 7 octobre, contrôlez au minimum les points suivants.

1. Requêtes suspectes dans les journaux du serveur web :

grep -E "bricksforge/v1/form_submit|action=bricksforge_form_submit" /var/log/nginx/access.log*
# (ou /var/log/apache2/access.log* selon votre serveur)

2. Fichiers PHP présents dans le dossier des médias, où ils n’ont rien à faire :

find wp-content/uploads -type f -iregex '.*\.\(php[0-9]?\|phtml\|phar\)' -ls
find wp-content/uploads -type f -iname 'login_admin_*.php' -ls

3. Comptes administrateurs récents ou inconnus :

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Au moindre doute, traitez le site comme compromis : isolez-le, changez tous les mots de passe et clés (y compris les clés de salage de wp-config.php), puis restaurez une sauvegarde saine antérieure au 7 octobre.

Durcir votre site pour la prochaine fois

Ce type d’attaque échoue si le serveur refuse d’exécuter du PHP dans le dossier des médias. C’est une règle simple à mettre en place sur tout site WordPress. Sous Nginx :

location ~* ^/wp-content/uploads/.*\.(php[0-9]?|phtml|phar)$ {
    deny all;
}

Sous Apache, dans un fichier wp-content/uploads/.htaccess :

<FilesMatch "\.(php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

Complétez avec un pare-feu applicatif (WAF), une veille sur les extensions installées (y compris celles achetées hors WordPress.org) et des sauvegardes externalisées dont vous avez déjà testé la restauration.

Notre avis d’agence

Cette faille le rappelle : sur WordPress, la porte d’entrée est rarement le cœur du CMS, et bien plus souvent une extension, surtout quand elle est mise à jour en dehors du circuit habituel. Entre la détection des premières attaques et la publication de la CVE, il ne s’est écoulé que quelques heures. Sans veille active, impossible de réagir à temps.

Vous utilisez Bricks et Bricksforge, ou vous ne savez pas quelles extensions tournent sur votre site ? Contactez-nous : nous pouvons vérifier votre installation et mettre en place le durcissement décrit ici.

Sources

Mots-clés