← Toutes les ressources

Faille Drupal Commerce exploitée : prix modifiables (28/10/2026)

Publié le 2 novembre 2026 · 7 min de lecture · CyberNovaLabs.io

Un contournement d'accès dans Commerce Core laissait un client écrire lui-même le prix et l'état de sa commande. Drupal l'a classé 21 sur 25, signale une exploitation en cours et demande d'auditer les commandes. Ce qu'une PME doit vérifier, et les deux horloges réglementaires qui peuvent partir.

En bref

Le 28 octobre 2026, l'équipe sécurité de Drupal a publié l'avis SA-CONTRIB-2026-254 et classé « hautement critique » (21 sur 25) une faille Drupal Commerce : un contournement d'accès dans Commerce Core, le module qui fait tourner les boutiques en ligne Drupal^[1]. Référencée CVE-2026-118539, elle touche toutes les versions antérieures à 2.41 ainsi que les versions 3.0.0 à 3.3.12, et l'avis indique qu'elle est déjà exploitée^[1]. Drupal comptait 42 002 sites déclarant utiliser Commerce la semaine du 18 octobre 2026^[3], et demande d'auditer les commandes à la recherche d'incohérences^[1].

Ce que la faille Drupal Commerce permet, concrètement

Commerce Core vérifiait les droits au niveau de l'entité, pas au niveau du champ. Autrement dit : le module contrôlait bien que vous ne touchiez que votre propre panier, mais pas quels champs de ce panier vous pouviez écrire. Un client authentifié pouvait donc, via les interfaces JSON:API et REST, écrire des champs qui ne lui appartiennent pas : total_price, unit_price, adjustments, state, uid et store_id sur la commande et ses lignes^[5].

Deux autres portes étaient ouvertes : le champ product_id d'une variation, qui permet de rattacher une déclinaison au produit d'un autre vendeur, et le champ promotion_id d'un coupon, avec le formulaire de gestion des coupons d'une commande^[5]. Drupal résume l'effet en une phrase : un contournement d'accès susceptible d'avoir un impact financier pour le marchand^[1].

La traduction commerciale est simple. Une commande peut passer à l'état « payée » sans paiement, ou être payée au prix que l'acheteur a lui-même écrit. Ce n'est pas un vol de base de données : c'est une perte sèche sur le chiffre d'affaires, ligne par ligne, qui ne déclenche aucune alerte de sécurité et qu'aucun antivirus ne voit.

Pourquoi « mon Drupal est à jour » ne suffit pas

Commerce Core n'est pas le cœur de Drupal : c'est un module contribué. Les mises à jour de sécurité du cœur et celles des modules contribués suivent deux calendriers et deux séries d'avis différents. Un site dont le cœur est parfaitement à jour peut donc rester vulnérable pendant des semaines sans que personne ne le remarque.

Le même 28 octobre, Drupal a publié un second avis sur la même pile : Commerce License, classé « modérément critique » (12 sur 25), CVE-2026-118555, corrigé en 3.1.1^[2]. Celui-là ne concerne que les sites ayant accordé la permission de mise à jour de ses propres licences, mais il peut mener jusqu'à un rôle d'administrateur^[2]. Si vous vendez des abonnements ou des licences, les deux avis vous concernent.

Enfin, le délai compte plus que la gravité. La faille est exploitée : chaque jour écoulé entre le 28 octobre et votre mise à jour est une fenêtre pendant laquelle des commandes ont pu être réécrites à la main. C'est le schéma déjà vu sur les failles critiques de PHP d'octobre 2026 : la question utile n'est pas « suis-je vulnérable », mais « qu'est-ce qui s'est passé avant que je corrige ».

Les deux horloges réglementaires, pays par pays

Une fraude sur les commandes ne déclenche pas automatiquement une obligation de signalement. Deux textes, deux conditions, deux destinataires.

NIS2. Pour les entités essentielles et importantes au sens de la directive, l'article 23 prévoit une alerte précoce dans les 24 heures, une notification dans les 72 heures, puis un rapport final dans le mois qui suit cette notification^[6]. Le destinataire est l'autorité ou le CSIRT national : le CCB en Belgique, le NCSC-NL aux Pays-Bas, l'ANSSI en France, l'ILR au Luxembourg. Encore faut-il être dans le champ d'application, ce qui dépend du secteur et de la taille : nos analyses détaillent le test pour les boutiques en ligne belges et pour les boutiques en ligne néerlandaises.

RGPD. L'article 33 impose une notification à l'autorité de protection des données dans les 72 heures après la prise de connaissance d'une violation de données à caractère personnel^[7] : APD/GBA en Belgique, Autoriteit Persoonsgegevens aux Pays-Bas, CNIL en France, CNPD au Luxembourg. Nuance utile : une commande payée au mauvais prix n'est pas, en soi, une violation de données personnelles. L'horloge des 72 heures ne part que si des données de clients ont été consultées, modifiées ou extraites — ce que seul l'examen des journaux permet d'établir.

Dans les deux cas, le point de départ est la prise de connaissance. C'est pourquoi la chronologie écrite — date de découverte, commandes touchées, montant, mesures prises — se prépare avant d'appeler qui que ce soit.

Chiffrer son exposition en dix minutes

Les chiffres qui suivent sont des hypothèses de travail, à remplacer par les vôtres.

Hypothèse : 40 commandes par jour, panier moyen de 120 euros, fenêtre de 6 jours entre l'avis du 28 octobre et votre correctif, 1 % de commandes manipulées. Cela donne 240 commandes exposées et un ordre de grandeur de 288 euros. À 10 % de commandes manipulées, on passe à 2 880 euros. L'intérêt du calcul n'est pas le résultat : c'est qu'il vous dit combien de commandes vous devez relire à la main, et donc combien de temps réserver cette semaine.

Chez CyberNovaLabs.io

Nous construisons et maintenons des boutiques et des outils métier, et nous tenons l'inventaire des composants qui les font tourner : c'est ce registre qui permet de répondre en une heure, et non en une semaine, à la question « sommes-nous concernés ». Si personne ne peut vous dire aujourd'hui quelle version de Commerce Core tourne en production, c'est le premier chantier. Voyez notre offre de logiciel sur mesure et de maintenance applicative, ou parlez-nous de votre boutique en trente minutes.

Sources

1. Drupal Security Team — Commerce Core - Highly critical - Access bypass - SA-CONTRIB-2026-254 (28/10/2026)
2. Drupal Security Team — Commerce License - Moderately critical - Access bypass - SA-CONTRIB-2026-260 (28/10/2026)
3. Drupal.org — Statistiques d'usage du module Commerce (semaine du 18/10/2026)
4. BleepingComputer — Drupal warns of critical Commerce Core flaw exploited in attacks (30/10/2026)
5. Ostorlab — Drupal Commerce Access Bypass, Exploited in the Wild (CVE-2026-118539) (30/10/2026)
6. Directive (UE) 2022/2555 (NIS2), article 23 — obligations de signalement
7. Règlement (UE) 2016/679 (RGPD), article 33 — notification d'une violation de données

À lire aussi