Checkout découplé sous Drupal Commerce : une faille corrigée, à vérifier

Le 23 septembre 2026, le projet Drupal a publié l’avis de sécurité SA-CONTRIB-2026-179 concernant Commerce Decoupled Checkout, un module qui expose des points de terminaison REST pour créer des commandes et gérer des paiements à distance depuis une boutique Drupal Commerce en architecture découplée. La faille, référencée CVE-2026-96378 et classée « modérément critique » (13/25), tient à un contrôle insuffisant des données envoyées à l’endpoint de création de commande : il était possible de fixer des propriétés de commande qui n’auraient jamais dû être accessibles depuis l’extérieur.

Ce que corrige la version 8.x-1.8

Avant le correctif, l’endpoint de création de commande acceptait tout champ transmis dans la requête, sans liste de champs autorisés. La version 8.x-1.8 introduit une liste blanche : par défaut, seuls le type de commande, l’adresse e-mail du client, la boutique cible et les lignes d’articles peuvent être définis par l’appel API. Toute demande d’ajout de champ personnalisé supplémentaire doit désormais être activée explicitement depuis l’interface d’administration, et toute requête qui sort de cette liste est rejetée. Le correctif a été développé par Leo Pitt et Marcus Johansson, ce dernier ayant également signalé la faille.

Qui est concerné

Ce module ne concerne que les boutiques Drupal Commerce dont le parcours de paiement est « découplé » : un site vitrine, une application mobile ou un front-end JavaScript qui ne passe pas par les formulaires Drupal classiques mais crée et paie les commandes via API, avec Stripe, PayPal ou Global Payments comme passerelle. C’est une configuration minoritaire mais réelle chez les e-commerçants qui ont fait le choix d’un front-end sur mesure. Le projet est en maintenance minimale : les mainteneurs suivent les tickets sans garantir un délai de réponse, ce qui déplace la responsabilité de la mise à jour vers chaque boutique et son prestataire technique.

Ce qu’il faut vérifier et faire

1. Identifier si le module Commerce Decoupled Checkout est installé sur la boutique, avec l’équipe technique ou l’agence en charge du site.
2. Contrôler la version actuellement en production : toute version antérieure à 8.x-1.8 est concernée.
3. Mettre à jour vers la version 8.x-1.8 dès que la fenêtre de maintenance le permet.
4. Reconfigurer après mise à jour la liste des champs de commande autorisés si des champs personnalisés sont réellement nécessaires côté front-end.
5. Vérifier les commandes récentes pour toute anomalie si l’endpoint était exposé publiquement sans restriction d’accès complémentaire.

Une vigilance qui dépasse ce seul module

Cette faille illustre un point plus général déjà abordé à propos du choix entre thème classique et architecture découplée : dès qu’une boutique laisse un front-end externe créer ou modifier des commandes par API, chaque champ accepté sans contrôle est une porte potentielle. La même logique de validation stricte des données entrantes vaut pour la sécurisation des étapes de paiement, comme le rappelait l’article sur DSP2 et l’authentification forte. Le choix de Drupal Commerce, déjà mis en regard de WooCommerce et PrestaShop dans le comparatif des trois plateformes, s’accompagne souvent d’une architecture découplée : c’est précisément cette combinaison qui rend ce type de correctif à surveiller de près pour les boutiques concernées.

Ce qu’il faut retenir

• Le module Commerce Decoupled Checkout pour Drupal Commerce a reçu un correctif de sécurité le 23 septembre 2026 (CVE-2026-96378, avis SA-CONTRIB-2026-179).
• Seules les boutiques en architecture découplée (front-end externe créant des commandes par API) sont concernées.
• La mise à jour vers la version 8.x-1.8 introduit une liste blanche des champs de commande modifiables par API.
• Un audit des commandes récentes est recommandé si l’endpoint était exposé sans restriction complémentaire.