Des attaquants exploitent activement un contournement d’autorisation critique dans Drupal Commerce Core
Le 30 octobre 2026, Drupal a prévenu que la CVE-2026-118539, un défaut d’autorisation dans le module Commerce Core, est exploitée dans la nature. Tout site marchand sous Drupal Commerce doit passer en version 3.3.13 ou 8.x-2.41 sans délai, puis vérifier ses commandes et ses prix.
30 octobre 2026. Drupal a publié l’avis de sécurité SA-CONTRIB-2026-254 pour avertir que la CVE-2026-118539 — un défaut d’autorisation dans le module Commerce Core — est « activement exploitée dans la nature ». Le score CVSS n’est pas encore attribué. Le point qui compte : ce n’est pas un correctif préventif, c’est un correctif sous pression d’exploitation, et il touche l’argent du marchand, pas seulement ses données.
Un module marchand, une autorisation qui ne tient pas
Commerce Core est le module qui transforme Drupal en boutique : panier, tunnel de commande, gestion des paiements, et une API pour les applications découplées. La vulnérabilité est un cas de missing authorization — un défaut d’autorisation manquant. Concrètement, selon l’avis, « le module ne protège pas suffisamment certains routes et champs d’entité, ce qui conduit à un contournement d’accès susceptible d’avoir un impact financier pour le vendeur ».
La formulation est inhabituelle et mérite qu’on s’y arrête. La plupart des avis de Drupal parlent de fuite de données ou d’exécution de code. Ici, l’éditeur pointe directement le préjudice financier du commerçant. Cela suggère que l’attaquant ne se contente pas de lire : il peut accéder à des routes et à des champs qui lui permettent de modifier ce qu’un client voit, commande ou paie — typiquement des prix, des remises, des états de commande ou des données de paiement.
Les versions concernées couvrent l’essentiel de la base installée : la branche 3.x de Commerce Core jusqu’à 3.3.13 incluse, et les versions antérieures jusqu’à 8.x-2.41. Autrement dit, tout site qui n’a pas appliqué le correctif publié le 30 octobre est potentiellement exposé.
Un correctif simple, un rayon d’action large
La correction tient en une mise à jour mineure :
- Branche 3.x — passer à Commerce Core 3.3.13.
- Versions antérieures — passer à Commerce Core 8.x-2.41.
C’est un upgrade de routine, sans changement de schéma ni migration lourde. Mais la simplicité du correctif ne doit pas masquer l’urgence : Drupal confirme une exploitation active, ce qui distingue cette faille d’une vulnérabilité simplement signalée. Le crédit du signalement revient à trois chercheurs — Dan Puccetti (dpuccetti), Marcus Johansson (marcus_johansson) et Robert Snyder (rsnyd) — qui l’ont remontée par le canal de divulgation responsable de la communauté.
Le module Commerce Core n’est pas un greffon confidentiel. C’est la brique marchande de référence de l’écosystème Drupal, utilisée par des distributeurs, des revendeurs B2B et des organisations publiques qui vendent en ligne. Une faille de cette nature, exploitée en amont d’un correctif largement déployé, a donc un rayon d’action qui dépasse de loin le site d’un artisan.
Ce que l’avis ne dit pas encore
Drupal n’a fourni aucun détail sur la nature de l’exploitation ni sur l’ampleur de la campagne. On ignore combien de sites ont été touchés, par quel vecteur l’attaquant entre, et s’il s’agit d’un acteur opportuniste qui balaie Internet ou d’une opération ciblée contre des marchands précis. Cette retenue est cohérente avec la pratique de l’éditeur, qui publie rarement les détails techniques tant que le correctif n’a pas eu le temps de se propager.
Cette absence d’information a une conséquence opérationnelle directe. Faute de proof of concept public à ce stade, la seule donnée exploitable est celle-ci : l’exploitation est réelle, elle vise un module qui touche au paiement, et la fenêtre entre la publication de l’avis et la correction effective de votre site est le moment où vous êtes le plus vulnérable.
La vérification qui suit le correctif
Appliquer 3.3.13 ou 8.x-2.41 ferme la faille, mais ne répare pas ce qu’un attaquant a pu faire avant. Le caractère « financier » de l’impact impose une post-vérification que l’on omet trop souvent après un correctif de sécurité classique. Trois contrôles méritent d’être faits dans les heures qui suivent la mise à jour :
- Commandes et paniers — rechercher des commandes modifiées, des remises anormales, des articles au prix nul, des changements d’état suspects.
- Règles de prix et promotions — vérifier que les règles de tarification, de remise et de taxe n’ont pas été éditées ou désactivées.
- Comptes à privilèges — chercher de nouveaux comptes administrateur ou des élévations de rôle récentes, puisque le contournement d’autorisation est précisément la porte d’entrée vers d’autres droits.
Pour un site marchand, ces trois vérifications ne sont pas un luxe : elles sont la différence entre « faille corrigée » et « faille corrigée mais déjà exploitée ».
# Vérifier la version installée de Commerce Core via Drush
drush pm:list --filter=commerce --status=enabled
# Puis mettre à jour vers le correctif (Composer)
composer require "drupal/commerce:^3.3.13" --with-all-dependencies
drush updatedb
drush cache:rebuildVerdict
Si vous exploitez un site Drupal avec Commerce Core, appliquez 3.3.13 ou 8.x-2.41 immédiatement : l’exploitation active ne laisse aucune marge pour reporter un correctif dont le coût est une simple mise à jour mineure, et l’impact « financier pour le vendeur » exige la post-vérification des commandes et des prix dans la foulée. Si vous gérez une place de marché ou un revendeur B2B à fort volume, traitez cette CVE comme un incident de sécurité, pas comme une maintenance : la valeur concentrée dans les commandes et les règles de prix fait de votre site une cible plus rentable qu’une boutique de détail. Et si vous n’utilisez pas Commerce Core, ne concluez pas trop vite : la leçon vaut pour tout module qui touche au paiement — un défaut d’autorisation y a un coût comptable immédiat, là où d’autres failles n’ont qu’un coût de réputation. La CVE-2026-118539 rappelle une règle simple que les marchands oublient : la sécurité d’un site d’e-commerce n’est pas une affaire de données, c’est une affaire de caisse.