La faille en un paragraphe, le reste est de la procédure
L'avis SA-CONTRIB-2026-254 concerne le module Commerce Core (drupal/commerce). Drupal.org le classe « Highly critical », 21 sur 25, et décrit un contournement d'accès : le module ne protège pas suffisamment certaines routes et certains champs d'entité. L'avis range le niveau d'authentification requis sous « tous / anonymes » et précise que la faille peut avoir des conséquences financières pour le vendeur. Il affirme aussi qu'elle est exploitée dans la nature.
L'avis ne nomme ni les routes ni les champs concernés. Nous n'en déduisons donc rien : ni liste de chemins à bloquer, ni signature à chercher dans les journaux. L'identifiant CVE-2026-118539 est relevé sur la page de l'avis ; nous ne l'avons pas recoupé avec la base NVD, citez-le donc comme « identifiant publié par l'avis » tant que ce recoupement n'est pas fait.
Tableau de référence : branche, version touchée, version corrigée
Faites défiler le tableau
| Votre situation | Statut selon l'avis | Action |
|---|---|---|
| Commerce 3.x, de 3.0.0 à avant 3.3.13 | Vulnérable | Passer en 3.3.13 ou plus récent |
| Commerce 2.x (8.x-2.x), avant 8.x-2.41 | Vulnérable | Passer en 8.x-2.41 ou plus récent |
| Commerce 3.3.13 ou 8.x-2.41 déjà installé | Corrigé | Auditer quand même les commandes passées avant la mise à jour |
| Drupal ^10.3 ou 11 | Branche 3.x annoncée compatible | Mettre à jour dans la branche 3.x |
| Drupal ^9.3 ou ^10 | Branche 2.x annoncée compatible | Mettre à jour dans la branche 2.x, sans changer de branche dans la foulée |
| Module absent de `composer.lock` | Hors périmètre de cet avis | Consigner l'absence dans l'inventaire |
| Boutique sans accès Composer ou code copié à la main | Version inconnue | Retrouver la version avant toute conclusion |
Pourquoi corriger ne suffit pas
L'avis le dit en toutes lettres : les sites doivent auditer leurs commandes, parce que la faille est exploitée. Une boutique passée en 3.3.13 aujourd'hui a pu être visitée avant. La mise à jour ferme l'accès ; elle ne remet pas en ordre une commande dont le montant, le statut ou l'état de paiement a été modifié. L'avis ne dit pas depuis quand l'exploitation a lieu : choisissez une fenêtre d'audit large, notez-la dans le dossier, et ne la réduisez pas au jour de la mise à jour.
Il y a ensuite un obstacle banal : sans inventaire central, personne ne sait quelles boutiques embarquent Commerce, ni dans quelle branche. La méthode d'inventaire est celle d'une faille de plugin WordPress, décrite dans notre guide Bricksforge. L'ordre de travail est donc : inventaire, sauvegarde, mise à jour, audit, preuve datée. Les boutiques qui encaissent le plus passent en premier.
Inventorier la version de Commerce sur chaque boutique
Lire la version avec Composer
cd /var/www/boutique-clientcomposer show drupal/commerce
La commande affiche la version installée. Pour la branche 2.x, drupal.org parle de 8.x-2.41 ; Composer présente le numéro sans le préfixe 8.x. Comparez le numéro, pas la chaîne. Le chemin est un exemple : adaptez-le à votre hébergement.Recouper avec Drush
drush pm:list --type=module --status=enabled --filter=commerce
La liste indique si Commerce est activé et dans quelle version. Un site peut porter le code sans que le module soit activé : notez-le, la situation change si quelqu'un l'active plus tard.Lire le verrou plutôt que le dossier
grep -A1 '"name": "drupal/commerce"' composer.lock
Le fichiercomposer.lockdit ce qui est réellement installé, sans démarrer Drupal. C'est la lecture la plus sûre sur une boutique que vous ne voulez pas solliciter pendant l'audit.Boucler sur toutes les boutiques d'un serveur
find /home -name composer.lock -not -path '*/vendor/*' -exec grep -H -A1 '"name": "drupal/commerce"' {} +
Chaque fichier cité contient Commerce, et la ligneversionsuit le nom. Relisez la liste : un dossier de test oublié ou une copie de sauvegarde compte aussi.Consigner le résultat dans un tableau
Une ligne par boutique : client, hébergeur, chemin, branche, version relevée, version de Drupal, date et heure du relevé. Ajoutez deux colonnes à remplir plus tard, « mise à jour faite » et « audit des commandes fait ». Ce tableau devient la pièce centrale du dossier remis aux clients.
Sauvegarder avant de toucher au code
Une mise à jour de module se défait mal sans point de retour. Avant chaque boutique : une sauvegarde de la base et du code, sur un support que la mise à jour ne touche pas, avec sa date relevée dans le tableau. Sur une boutique active, la base change à chaque commande : la sauvegarde fixe l'état à partir duquel vous pourrez comparer les commandes après coup. Ne l'écrasez pas par la suivante tant que l'audit n'est pas clos. Elle sert deux fois : revenir en arrière, et prouver ce que contenait la boutique avant la correction.
Mettre à jour une boutique
Figer l'état
drush sql:dump --gzip --result-file=/chemin/sauvegarde/boutique-avant.sql
Copiez aussi le dossier du projet : code,composer.json,composer.locket fichiers. Notez l'emplacement de la copie dans le tableau.Vérifier ce que la contrainte Composer autorise
composer why-not drupal/commerce 3.3.13
Sicomposer.jsonfige une version, cette commande nomme ce qui bloque. Une boutique en 2.x reste en 2.x et vise 8.x-2.41 : un changement de branche est un chantier distinct, à planifier à part.Mettre à jour le module et ses dépendances
composer update drupal/commerce --with-dependencies
Relisez la liste des paquets modifiés avant de valider : un autre module Commerce peut bouger avec lui.Appliquer les mises à jour de base
drush updatedb -ydrush cache:rebuild
La première commande exécute les mises à jour de schéma éventuelles, la seconde vide les caches.Contrôler la version installée
Relancez
composer show drupal/commerce. La version doit atteindre 3.3.13 sur la branche 3.x, ou le numéro 2.41 sur la branche 2.x. Reportez-la dans le tableau, avec la date et l'heure.Passer une commande de test
Sur la préproduction, ou en mode test de la passerelle de paiement, ajoutez un produit au panier, passez la commande et vérifiez le montant, le statut et le paiement. Une mise à jour qui casse le tunnel d'achat doit se voir avant le client.
Une procédure par environnement
Le même correctif ne se joue pas de la même façon partout. Le tableau suivant fixe, pour chaque environnement, le geste attendu et la preuve à conserver. Une préproduction publique compte comme une boutique.
Les mises à jour automatiques du système, décrites dans notre guide sur Debian et Ubuntu, ne touchent pas à un module Drupal : ce geste reste celui de l'agence.
Développement, préproduction, production : le geste et la preuve
Faites défiler le tableau
| Environnement | Geste | Preuve à garder |
|---|---|---|
| Production | Sauvegarde, mise à jour, `drush updatedb`, commande de test, puis audit | Sauvegarde datée, version relevée, résultat de l'audit |
| Préproduction accessible depuis Internet | Mettre à jour en premier si le code est identique, ou la protéger par mot de passe en attendant | Version relevée, protection retenue |
| Préproduction fermée ou locale | Mettre à jour et rejouer la commande de test avant la production | Capture de la commande de test, date |
| Développement | Aligner `composer.lock` sur la production pour ne pas réintroduire l'ancienne version au prochain déploiement | Commit du verrou, version relevée |
| Copie ou sauvegarde restaurée | Ne jamais la remettre en ligne sans la mise à jour | Mention dans le dossier client |
Auditer les commandes sans présumer de la méthode de l'attaquant
Fixer la fenêtre
Choisissez une date de début large et notez-la. L'avis ne donne pas de date de début d'exploitation : prenez au minimum la période couverte par vos sauvegardes et vos journaux, et écrivez pourquoi.
Lister les commandes de la fenêtre
Exportez les commandes avec leur numéro, leur date de création et de passage, leur statut, leur total et leur devise. L'interface d'administration suffit. En base, commencez par lire les noms de colonnes :
drush sql:query "DESCRIBE commerce_order"
Les noms exacts dépendent de votre version : ne les supposez pas.Chercher les écarts internes
Pour chaque commande, comparez le total au calcul des lignes et des ajustements. Un total qui ne correspond pas à ses lignes, une remise que personne n'a configurée, ou un prix de ligne différent du catalogue : chaque écart est à instruire.
Croiser avec la passerelle de paiement
Une commande terminée sans paiement correspondant chez le prestataire, ou un paiement d'un montant différent du total, mérite un examen. Le relevé du prestataire fait foi pour l'argent encaissé : faites le croisement sur les exports, pas sur ce que la boutique affiche.
Regarder les passages d'état
Repérez les commandes dont le statut a changé sans action humaine ni paiement cohérent : validées sans passage par le paiement, ou arrivées à un statut final en quelques secondes. Les journaux d'accès aident à dater ce qui s'est passé. L'avis ne détaille aucune route : une recherche par chemin est un indice, jamais une preuve d'absence.
Ce que l'audit ne prouve pas
Un audit propre dit qu'aucune incohérence n'est visible dans les commandes. Il ne dit pas qu'aucune requête n'a abusé de la faille : l'avis parle de routes et de champs d'entité sans les nommer. Écrivez dans le rapport ce que vous avez regardé, et ce que vous n'avez pas regardé.
Si une commande est incohérente
- Ne rien supprimer — conservez la commande, ses paiements et la sauvegarde datée : ce sont les pièces du dossier.
- Suspendre la livraison — bloquez l'expédition ou l'accès au produit numérique tant que le paiement n'est pas confirmé chez le prestataire.
- Prévenir le client de l'agence — votre rapport indique la commande, l'écart constaté, la date et le montant concerné.
- Interroger le prestataire de paiement — il tient le relevé des encaissements ; demandez le détail de la transaction.
- Conserver les journaux — copiez les journaux d'accès et de l'application de la période avant leur rotation.
- Contrôler les comptes — si vous trouvez un compte ou un rôle que personne n'a créé, changez les mots de passe d'administration et les clés de la passerelle.
- Mesurer avant de restaurer — revenir à une sauvegarde d'avant l'incident efface aussi les commandes légitimes passées depuis.
Les autres avis Commerce du même jour
Le 28 octobre 2026, drupal.org a publié d'autres avis qui touchent l'écosystème Commerce, du numéro 255 au numéro 265 : Commerce Core, Commerce Shipping, Commerce License et Commerce Stripe. Ils sont classés moins graves que le 254, et seul le 254 déclare une exploitation dans la nature. L'un d'eux, sur Commerce Stripe, atteint pourtant « Critical » (15 sur 25).
Ne mettez donc pas à jour que Commerce Core. Listez les paquets Commerce de chaque boutique avec composer outdated 'drupal/commerce*' et lisez chaque avis sur drupal.org/security avant de décider.
Qui tient la relation client, et ce que vous remettez
Quand une commande frauduleuse est trouvée, c'est l'agence que le client appelle. Gardez ce rôle : l'agence tient la relation, le rapport d'audit et la décision de remboursement ou de restauration. La plateforme tient l'infrastructure : un compte isolé par client, des sauvegardes à restaurer, un accès SSH ou WHM pour mettre à jour sans attendre un ticket. Nous ne modifions pas le code applicatif d'une boutique à votre place ; la mise à jour de Commerce reste un geste de l'agence.
Remettez au client une page datée : version avant, version après, date et heure de la mise à jour, référence de la sauvegarde, fenêtre d'audit, nombre de commandes examinées, écarts trouvés ou absence d'écart, et ce qui n'a pas été regardé. Gardez le modèle : le prochain avis sur un module Drupal suivra la même séquence, avec une autre ligne dans l'inventaire. Le rythme mensuel de contrôle est décrit dans la checklist d'audit d'un VPS client.
