flawopen.com/Incidents/bricksforge-pro-forms-upload-metadata-october-2026

● Bricksforge WordPress plugin · CVE-2026-85097 · 2026-10-07 · CVSS 9.8 · Critique

Recherche · FlawOpen

CVE-2026-85097 dans Bricksforge : faille d’envoi Pro Forms

CVE-2026-85097 permettait à des requêtes sans authentification d’exploiter l’écart entre le contenu validé d’un fichier temporaire et les métadonnées de destination contrôlées par le client dans Bricksforge Pro Forms. Patchstack signale des tentatives d’exploitation ; mettez le plugin à jour et examinez les sites exposés.^{[1], [2], [3], [4], [5]}

💡 Explication en Langage Simple (ELI5)

Imaginez un service courrier qui vérifie qu’un colis contient une image inoffensive, puis laisse l’expéditeur changer l’étiquette avant de l’envoyer dans un bureau qui ouvre certaines étiquettes comme des programmes. Bricksforge vérifiait le fichier temporaire, mais l’envoi ultérieur du formulaire pouvait fournir un autre nom de destination. La défense consiste à garder l’identité et la destination du fichier sous le contrôle du serveur pendant tout le stockage.^{[3], [2]}

Concepts Clés et Termes

Envoi temporaire: Fichier placé en attente avant la fin d’un formulaire. Sa validation à cette étape ne rend pas fiables les métadonnées fournies ensuite par le client.^{[2], [3]}
CWE-434: Téléversement sans restriction d’un type dangereux : le système accepte un fichier susceptible d’être interprété ou exécuté de façon risquée.^{[1], [2]}
Frontière de confiance des métadonnées: Point où l’application détermine si un nom, une URL, un type MIME ou un chemin vient d’un enregistrement serveur fiable ou d’un client non fiable.^{[2], [3]}
Score CVE et exploitation: La fiche CVE de la CNA Wordfence attribue CVSS 3.1 9.8 et l’enrichissement CISA indique qu’aucune exploitation n’est connue. Patchstack attribue 10.0 et rapporte une télémétrie observée pour la première fois le 7 octobre 2026. Ces constats restent attribués séparément ; aucun ne confirme une inscription au CISA KEV.^{[1], [2], [3], [4]}
Code illustratif: La comparaison PHP ci-dessous modélise la frontière de validation de façon générique. Ce n’est ni le code Bricksforge ni une reconstitution de son correctif ; le journal de versions cité ne publie pas ces détails.^{[2], [3], [5]}

Correspondances de référentiels

Référence CWE pour la faiblesse décrite dans ce guide : CWE-434

Versions signalées et mesures pour les opérateurs

Source des éléments	Ce qu’elle indique	Action défensive
Enregistrement CNA Wordfence / CVE	Décrit un téléversement arbitraire de fichiers sans authentification ; la plage affectée enregistrée se termine à la version 3.1.8.9.	Considérez ceci comme le périmètre enregistré par la CNA, pas comme une preuve qu’une installation est saine.
Patchstack (8 oct. 2026)	Signale des tentatives d’exploitation observées pour la première fois le 7 octobre et indique que la version 3.1.8.10 corrige le problème.	Considérez cela comme le seuil de correction indiqué par Patchstack ; vérifiez la version réellement installée sur chaque site.
Journal public des modifications Bricksforge	La version 4.0.1 mentionne une correction de sécurité des téléversements Pro Forms, sans préciser le seuil 3.1.8.10.	Ne déduisez pas du seul journal que la 4.0.1 est la première version corrigée ni qu’une version 3.x donnée est sûre.
Site exposé ou suspicion de compromission	Les sources décrivent des tentatives d’exploitation, pas la compromission avérée de chaque site ciblé.	Passez à une version actuellement prise en charge ; examinez les journaux de téléversement et du serveur Web, puis enquêtez sur tout fichier inattendu avant de déclarer le rétablissement.

Chronologie de l'Incident

2026-10-07

Wordfence indique le 7 octobre comme date de publication publique de l’avis. Patchstack affirme que sa télémétrie a observé les premières tentatives ce jour-là à 21 h 47 UTC ; publication de l’avis et observation télémétrique sont deux événements distincts.^{[2], [3]}

2026-10-08

La fiche CVE indique datePublished au 8 octobre, un jour après la date de publication publique du 7 octobre indiquée par Wordfence. Le rapport de campagne de Patchstack indique également une publication le 8 octobre ; il s’agit de dates distinctes de fiches et de publications.^{[1], [2], [3]}

2026-10-08

L’analyse de Patchstack du 8 octobre décrit l’écart de validation et les tentatives observées, et désigne la version 3.1.8.10 comme corrigée. Le journal de Bricksforge mentionne séparément un correctif de sécurité des téléversements Pro Forms en 4.0.1, sans établir la version corrective exacte de la branche 3.x.^{[3], [4], [5]}

Déroulement de l'Attaque Étape par Étape

Étape 1

Un fichier temporaire passe un premier contrôle

La CNA décrit un envoi temporaire préalable qui passe la validation MIME. Cela n’autorise pas des changements arbitraires ultérieurs de nom ou de destination.^{[2], [1]}

Étape 2

Le formulaire fournit d’autres métadonnées

Patchstack indique que le traitement ultérieur faisait confiance aux métadonnées temporaryFileUploads envoyées par le client, notamment à une URL pouvant différer du fichier déjà validé. Le défaut sépare le contenu contrôlé de la destination non contrôlée.^{[2], [3]}

Étape 3

Le fichier reçoit un nom dangereux

Si le serveur utilise cette destination contrôlée par le client pour finaliser l’envoi, une extension risquée peut provoquer une interprétation côté serveur si la destination est exécutable. Cette explication reste générale ; aucun format de requête ni contenu malveillant n’est nécessaire.^{[2], [3]}

Étape 4

L’exposition peut compromettre le serveur

La CNA indique que le problème peut permettre l’exécution arbitraire de PHP. Patchstack rapporte des tentatives et recommande une mise à jour. Ces observations ne prouvent pas que chaque site ciblé a été compromis ni n’identifient un acteur.^{[2], [3]}

Code Source : Vulnérable vs Sécurisé

Cet exemple générique montre une identité d’envoi gérée par le serveur, une recherche par utilisateur, une nouvelle vérification du type de contenu, des noms générés et un stockage privé. Ce n’est ni le code Bricksforge ni son correctif réel. Le code de production doit aussi imposer des limites de taille, des permissions sûres, des transitions d’état atomiques et une diffusion adaptée au contexte ; la correction directe consiste à mettre à jour Bricksforge vers une version corrigée prise en charge.^{[2], [3]}

IMPLÉMENTATION VULNÉRABLE

function finalize_upload( array $item, string $stagedPath, string $uploadDir ): string {
    // Les métadonnées du client choisissent le nom final après une première vérification MIME.
    $name = basename( (string) parse_url( $item['file']['url'], PHP_URL_PATH ) );
    $destination = $uploadDir . DIRECTORY_SEPARATOR . $name;
    if ( ! rename( $stagedPath, $destination ) ) {
        throw new RuntimeException( 'Could not finalize upload' );
    }
    return $destination;
}

PATCH SÉCURISÉ ET ROBUSTE

function finalize_upload( string $uploadId, UploadRegistry $registry, string $privateDir ): string {
    // Déterminez le propriétaire et le chemin depuis un enregistrement côté serveur, jamais depuis une URL cliente.
    $upload = $registry->findPendingForCurrentUser( $uploadId );
    if ( $upload === null || ! is_file( $upload->path ) ) {
        throw new RuntimeException( 'Unknown pending upload' );
    }
    $types = [ 'image/jpeg' => 'jpg', 'image/png' => 'png' ];
    $mime = ( new finfo( FILEINFO_MIME_TYPE ) )->file( $upload->path );
    if ( ! isset( $types[ $mime ] ) ) {
        throw new RuntimeException( 'Unsupported file type' );
    }
    $destination = $privateDir . DIRECTORY_SEPARATOR . bin2hex( random_bytes( 16 ) ) . '.' . $types[ $mime ];
    if ( ! rename( $upload->path, $destination ) ) {
        throw new RuntimeException( 'Could not finalize upload' );
    }
    $registry->markConsumed( $uploadId );
    return $destination;
}

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Inventoriez les versions de Bricksforge en production, en préproduction et chez les clients gérés ; mettez à jour les installations concernées vers la version prise en charge la plus récente. Patchstack désigne 3.1.8.10 comme corrigée, tandis que le journal fournisseur décrit le correctif en 4.0.1 sans préciser la limite exacte de la branche 3.x.^{[1], [2], [3], [4], [5]}
✓Conseil opérationnel de FlawOpen : Considérez tout nom, URL, chemin et libellé MIME fourni par le client comme non fiable lors de la finalisation ; dérivez le nom et le chemin stockés d’un enregistrement serveur et d’une liste autorisée fondée sur le contenu inspecté.
✓Conseil opérationnel de FlawOpen : Stockez si possible les fichiers hors des racines Web exécutables ; sinon, configurez le serveur Web pour interdire l’exécution de scripts dans tous les répertoires de dépôt et temporaires.
✓Conseil opérationnel de FlawOpen : Liez chaque dépôt en attente à la session du formulaire qui l’a créé, rendez-le utilisable une seule fois et refusez les identifiants absents, expirés, rejoués ou incohérents.
✓Conseil opérationnel de FlawOpen : Si un site vulnérable était accessible publiquement, examinez les journaux Web et applicatifs pour repérer des envois inhabituels et de nouveaux fichiers ; préservez les preuves et suivez le processus de réponse à incident de l’hébergeur avant tout nettoyage.
✓Conseil opérationnel de FlawOpen : Ajoutez des tests de régression pour les métadonnées incohérentes, les contenus interdits et les identifiants d’une autre session, expirés ou rejoués ; vérifiez leur rejet et l’absence d’écriture dans un emplacement exécutable.