Drupal Commerce Core : faille exploitée, passez à la 3.3.13 sans attendre

Des attaquants exploitent une faille hautement critique dans Drupal Commerce Core, le module de panier d'achat du système de gestion de contenu Drupal, pour passer des commandes qu'ils ne paient jamais. L'équipe de sécurité de Drupal a publié l'avis SA-CONTRIB-2026-254 le 28 octobre 2026 et indique que le bug « est activement exploité dans la nature ». Chaque boutique qui utilise le module a besoin de deux choses cette semaine : la mise à jour 3.3.13 ou 8.x-2.41, et un audit des commandes récentes.

La faille porte l'identifiant CVE-2026-118539. Drupal la note 21 sur 25, sa catégorie « Highly critical », avec le vecteur AC:None/A:None/CI:Some/II:Some/E:Exploit/TD:All. En clair : aucune connexion ni accès particulier n'est nécessaire, les données peuvent être lues et modifiées, et un exploit existe.

Ce que la faille permet à un attaquant

Le module « ne protège pas suffisamment certaines routes et certains champs d'entité », dit l'avis. C'est un contournement d'accès : un visiteur peut atteindre des pages et des champs de données qui auraient dû être verrouillés. BleepingComputer rapporte qu'un attaquant non authentifié peut s'en servir pour contourner les règles d'accès de la boutique.

Centarro, l'entreprise qui maintient Drupal Commerce, a décrit les attaques dans un billet de son PDG Ryan Szrama le 29 octobre. Les marchands ont constaté quatre types d'abus :

• Des commandes passées directement, en sautant le paiement, si bien que la commande existe mais n'a jamais été réglée.
• Des commandes affichées comme payées dans l'écran de gestion sans aucun enregistrement de paiement derrière, surtout sur les sites qui exposent le service web JSON:API.
• Des prix de produits abaissés avant le passage en caisse.
• Des remises, frais ou autres ajustements qu'aucun employé ni aucune promotion n'a ajoutés.

« Nous avons reçu deux signalements de tentatives, par des utilisateurs malveillants, de passer des commandes frauduleuses », a écrit Szrama. Certaines commandes affichaient des prix manifestement faux, comme 0,01 dollar. D'autres utilisaient des prix normaux. « À ce jour, nous ne pensons pas que l'attaque ait été automatisée ni exploitée au-delà des premiers sites », a-t-il ajouté. L'équipe de sécurité de Drupal a coordonné les tests, l'empaquetage et la publication du correctif le 28 octobre.

Qui est concerné et quoi installer

Drupal crédite Dan Puccetti, Marcus Johansson et Robert Snyder pour le signalement de la faille. Six personnes, dont Szrama, sont créditées pour le correctif. BleepingComputer évalue la base installée du module à plus de 42 000 sites web, en citant la page du projet sur drupal.org.

Branche	Versions concernées	Version corrigée	Prérequis Drupal (selon Rescana)
Commerce Core 3.x	De 3.0.0 jusqu'à 3.3.13 exclue	3.3.13	Drupal 10.3 ou plus récent, ou Drupal 11
Commerce Core 8.x-2.x	Toute version antérieure à 8.x-2.41	8.x-2.41	Drupal 9.3 ou plus récent, ou Drupal 10

Le correctif ne s'arrête pas à Commerce Core. Selon Centarro, Commerce API, Commerce License, Commerce Shipping et Commerce Stripe ont aussi reçu des versions de sécurité le 28 octobre et doivent être mis à jour en même temps. Rescana note que Drupal a publié en parallèle cinq avis Commerce Core moins graves, SA-CONTRIB-2026-255 à 259. Un avis Stripe distinct, SA-CONTRIB-2026-263, est classé critique et pourrait permettre à un attaquant de marquer une commande comme payée sans payer.

Centarro rappelle aussi aux utilisateurs de la 8.x-2.x que le support de cette branche prend fin à la sortie de Drupal 12. « Nous recommandons de passer à la 3.x dès que possible », dit le billet.

Depuis combien de temps la brèche est ouverte

Le bug est ancien. Selon Centarro, les exploits étaient « théoriquement possibles » depuis Commerce Core 8.x-2.18, publiée le 26 mai 2020, sur les sites qui utilisent JSON:API. Pour tous les autres sites, la fenêtre s'est ouverte avec la 8.x-2.25 le 30 juin 2021. Centarro présente ces dates comme les plus anciennes possibles, pas comme des dates d'attaque confirmées.

La faille ne figurait pas dans le catalogue des vulnérabilités exploitées connues (KEV) de la CISA dans l'édition du 29 octobre, rapporte Rescana. L'étiquette « activement exploitée » vient de Drupal et de Centarro eux-mêmes. La CISA a signalé cinq failles Drupal comme exploitées au fil des ans, selon BleepingComputer, la dernière étant un bug d'injection SQL, CVE-2026-9082, ajouté en mai 2026. Le cœur de Drupal lui-même a corrigé une faille critique d'exécution de code dans Field UI il y a deux semaines à peine.

Comment auditer vos commandes

Le correctif ferme la porte. Il n'annule pas les commandes déjà passées par cette porte. L'avis de Drupal dit que les sites « doivent auditer leurs commandes à la recherche d'incohérences ». Le billet de Centarro donne quatre vérifications en base de données, chacune sous forme de requête que les propriétaires de boutique peuvent exécuter :

1. Les commandes passées hors du tunnel de paiement qui ont encore un solde dû.
2. Les commandes dont le montant payé enregistré dépasse les paiements effectivement effectués.
3. Les lignes de commande dont le prix unitaire a été remplacé. Centarro note que la première vérification manquerait un prix abaissé à 0,01 dollar puis payé.
4. Les ajustements, comme des frais ou des remises personnalisés, qui ne viennent pas d'une promotion.

Un résultat n'est pas une preuve de fraude. Les commandes passées par le personnel et les produits « à prix libre » correspondent aussi, donc chaque commande signalée demande un regard humain. Rescana ajoute que croiser les adresses IP et les horaires des commandes signalées avec les journaux d'accès des parcours de paiement normaux aide à séparer les deux.

Le conseil opérationnel de Centarro est plus direct : n'expédiez pas une commande parce qu'elle a été passée ou parce que le paiement est terminé. Confirmez d'abord le paiement. Et si votre site n'a pas besoin que JSON:API accepte des modifications, passez-le en lecture seule.

Ce que cela signifie pour les développeurs

• Corrigez aujourd'hui, puis auditez jusqu'en 2020. Le correctif est une mise à jour composer ordinaire vers 3.3.13 ou 8.x-2.41, plus les quatre modules compagnons. L'audit est la partie lente. Si votre site expose JSON:API depuis mai 2020, les quatre requêtes doivent couvrir cinq ans de commandes, pas la semaine dernière.
• Traitez « affichée comme payée » comme une affirmation, pas un fait. Le deuxième type d'attaque crée des commandes que l'écran d'administration déclare payées sans entité de paiement derrière. Toute automatisation d'expédition qui se fie au seul état de la commande faisait confiance à un champ que l'attaquant pouvait fixer. Vérifiez que votre étape d'expédition lit les enregistrements de paiement, pas l'état de la commande.
• Les boutiques headless portent plus de risque. Les deux types d'attaque liés à JSON:API, et la date de départ plus ancienne de 2020, s'appliquent aux sites découplés. Si l'API ne sert que des données produit à une interface, passez-la en lecture seule maintenant, quelle que soit votre version de Drupal.
• Surveillez les avis compagnons. Le correctif critique distinct de Commerce Stripe concerne quiconque utilise Stripe comme passerelle. Mettez-le à jour dans le même déploiement que Commerce Core.
• Signalez tout ce qui semble anormal. Centarro dit qu'elle « préfère toujours examiner des faux positifs ou des doublons plutôt que de ne pas apprendre l'existence d'une vulnérabilité potentielle ». Deux signalements de marchands ont trouvé ce bug après cinq ans dans le code.