# Drupal Commerce : une commande peut devenir un problème d’autorisation

> Drupal confirme l’exploitation de CVE-2026-118539, un accès insuffisamment protégé aux routes et champs de Commerce Core. Risque financier, enquête et correctif.

Publié le: 2026-11-04  
Canonical: https://rootzero.eu/research/drupal-commerce-controle-acces-commandes-2026/

**Avis de sécurité du 28 octobre 2026.** [L'équipe Drupal](https://www.drupal.org/sa-contrib-2026-254) indique que **CVE-2026-118539** touche Commerce Core : certaines routes et certains champs d'entités ne sont pas suffisamment protégés. Elle confirme une exploitation active et avertit d'un possible impact financier pour le vendeur. Le mécanisme public est un **contournement de contrôle d'accès**, pas une RCE. C'est précisément ce qui rend le dossier utile : dans une boutique, altérer une donnée métier ou atteindre une route interne peut coûter de l'argent sans prendre la main sur le serveur.

## Deux points de décision différents

Une route répond à la question « qui peut appeler cette opération ? ». Un champ d'entité répond à « qui peut lire ou modifier cette partie de l'objet ? ». Protéger la route sans contrôler les champs qu'elle expose laisse potentiellement passer une modification interdite ; protéger les champs sans restreindre une route qui orchestre une opération sensible crée une autre ouverture. Les API dites *découplées* rendent cette séparation encore plus importante, car un client peut envoyer des demandes directement, sans passer par les écrans de la boutique.

Le [bulletin Drupal](https://www.drupal.org/sa-contrib-2026-254) ne nomme pas les routes, les champs ni une transaction frauduleuse précise. Il serait donc abusif d'affirmer que cette CVE permet toujours de fixer son propre prix, de marquer une commande comme payée ou de lire toutes les données client. Ces scénarios illustrent ce qu'un audit doit chercher dans une boutique, **pas** ce que l'avis établit pour cette faille. Le fait documenté est l'accès insuffisamment contrôlé avec risque financier et exploitation réelle.

## Comment établir l'impact sur un site donné

Un test autorisé peut construire une matrice de rôles : visiteur, client propriétaire d'une commande, autre client et opérateur. Pour chaque route concernée par le flux de commande, il compare les opérations permises sur une entité appartenant au demandeur et sur une entité qui ne lui appartient pas. Il vérifie séparément lecture, écriture, transitions d'état et champs calculés. Le résultat attendu ne se déduit pas du seul code HTTP : une réponse `200` peut être légitime pour une lecture publique, tandis qu'un changement silencieux d'un champ de paiement ou de livraison peut être critique.

Une revue du correctif permettrait d'identifier les contrôles ajoutés et d'écrire des tests de non-régression ciblés. Avant cette revue, la prudence consiste à maintenir la description au niveau publié par le projet. Drupal conseille en outre d'**auditer les commandes pour rechercher des incohérences**, preuve que la réponse doit traiter les effets métier déjà possibles, ainsi que la version du module.

## Version, preuve et suite

Les branches affectées sont **3.0.0 à 3.3.12** et les versions antérieures à **2.41** de la branche 2.x ; Drupal demande **3.3.13** ou **8.x-2.41** selon la ligne utilisée. L'inventaire doit relever la version de Commerce Core réellement déployée, y compris les environnements de boutique dont l'API est exposée. En cas de soupçon, les journaux applicatifs, l'historique des commandes, les transitions de statut et les écarts de règlement doivent être rapprochés. L'absence de malware serveur ne répond pas à une fraude effectuée par une opération applicative autorisée à tort.

Le cas rappelle que l'autorisation est une propriété de chaque **action et de chaque donnée**, au-delà de la page affichée. C'est une frontière que les tests d'intrusion doivent vérifier avec des comptes de rôles différents et des objets appartenant à d'autres utilisateurs.

**Source principale :** [Drupal Security Advisory SA-CONTRIB-2026-254](https://www.drupal.org/sa-contrib-2026-254).