Drupal a publié le 28 octobre 2026 un avis de sécurité qualifiant de « hautement critique » une faille de son module Commerce Core, utilisé par des boutiques en ligne bâties sur Drupal. CVE-2026-118539 est un contournement des contrôles d’accès qui, selon l’éditeur et plusieurs médias spécialisés dont The Hacker News et BleepingComputer, fait déjà l’objet d’une exploitation active. Plus de 42 000 sites e-commerce seraient potentiellement concernés.
Qu’est-ce que CVE-2026-118539 ? #
CVE-2026-118539 désigne une absence de contrôle d’autorisation (access bypass) dans Commerce Core, le module qui gère le panier, le paiement et les commandes des boutiques Drupal, que ce soit via l’interface classique ou via des applications découplées consommant son API. Selon l'avis officiel de Drupal (SA-CONTRIB-2026-254), certaines routes et certains champs d’entités ne sont pas suffisamment protégés : un attaquant peut ainsi accéder à des données ou des actions qui devraient rester réservées à un rôle autorisé, avec un risque de préjudice financier direct pour le vendeur (modification de prix, de statut de commande ou de remises, par exemple).
Drupal classe la faille « hautement critique », avec un score de 21 sur 25 selon son propre système de notation (et non un score CVSS chiffré). L’avis confirme que la vulnérabilité est « actively exploited in the wild », sans détailler la nature ni l’ampleur des attaques observées. The Hacker News reprend cette même information et attribue le signalement de la faille à trois chercheurs : Dan Puccetti, Marcus Johansson et Robert Snyder.
À retenir : contrairement à une exécution de code à distance, cette faille permet un contournement des contrôles d’accès. L’impact porte d’abord sur l’intégrité des commandes et des données de la boutique, pas nécessairement sur la prise de contrôle du serveur.
Versions concernées et correctif #
| Branche Commerce Core | Versions affectées | Version corrigée |
|---|---|---|
| 2.x | 0.0.0 à 2.41 | 8.x-2.41 |
| 3.x | 3.0.0 à 3.3.13 | 3.3.13 |
Les deux branches sont donc concernées, qu’un site tourne sur une version ancienne (2.x) ou récente (3.x) du module. Drupal n’indique pas de contournement temporaire fiable en dehors de la mise à jour : la seule mesure réellement efficace est d’installer la version corrigée dès que possible.
Comment se protéger ? #
- Identifier la version installée de Commerce Core sur chaque site Drupal de l’organisation, y compris les sites secondaires ou de test parfois oubliés.
- Mettre à jour sans délai vers Commerce Core 3.3.13 pour la branche 3.x, ou 8.x-2.41 pour les versions antérieures.
- Auditer les commandes récentes, comme le recommande l’avis officiel de Drupal : rechercher des incohérences de prix, des statuts de commande modifiés sans action légitime, ou des remises appliquées de façon anormale.
- Vérifier les comptes et rôles ayant accès au back-office de la boutique, pour détecter une élévation de privilèges ou un accès qui n’aurait pas dû être possible.
- Conserver les journaux applicatifs de la période précédant le correctif : en cas de doute sur une commande ou un compte suspect, ils seront nécessaires pour une investigation plus poussée.
Aucun indicateur de compromission public et vérifié n’est disponible à ce jour. L’audit manuel des commandes reste donc la méthode la plus fiable pour évaluer un impact éventuel sur un site resté exposé.
L’avis du CSIRT #
Pour un e-commerçant, la priorité n’est pas la même selon la taille du site. Une boutique à fort volume de commandes, avec des remises ou des statuts de paiement automatisés, doit traiter cette faille en urgence : le risque principal est financier et peut passer inaperçu plusieurs jours si personne ne rapproche les commandes des paiements réellement encaissés. Un site vitrine à faible trafic peut planifier la mise à jour dans la journée, sans attendre, mais sans urgence absolue.
La détection ne repose pas ici sur une signature technique précise, puisque la faille touche la logique métier plutôt qu’un composant facilement journalisé. Il faut raisonner en termes de cohérence : des commandes dont le montant ne correspond pas au panier initial, des changements de statut (« payé », « expédié », « remboursé ») sans action correspondante dans l’interface d’administration, ou des remises appliquées à des comptes qui n’y ont normalement pas droit.
Le piège le plus fréquent sur ce type de faille est de considérer le correctif comme suffisant en lui-même. Mettre à jour empêche de nouvelles tentatives, mais ne répare pas les commandes déjà altérées si le site était exposé avant la publication de l’avis. Après la mise à jour, il faut donc systématiquement croiser, sur la période à risque, les commandes du site avec les encaissements réels côté prestataire de paiement, et vérifier qu’aucun compte administrateur inconnu n’a été créé entre-temps.
Points clés #
- CVE-2026-118539 est une faille de contournement d’accès dans Commerce Core, module e-commerce de Drupal, classée « hautement critique » par l’éditeur.
- Elle est activement exploitée selon l’avis officiel de Drupal, sans détail public sur la méthode d’exploitation.
- Plus de 42 000 sites seraient potentiellement concernés ; les branches 2.x et 3.x sont toutes deux touchées.
- La seule protection fiable est la mise à jour vers 8.x-2.41 ou 3.3.13, suivie d’un audit des commandes récentes.
- Aucun indicateur de compromission public n’est disponible : l’audit manuel reste la seule vérification sérieuse en cas de doute.
Pour suivre une vulnérabilité par identifiant, la base CVE de ForenShield recense les failles publiées, et le calculateur CVSS aide à en qualifier la criticité selon votre contexte. D’autres chaînes de vulnérabilités de CMS récentes, comme celle touchant WordPress avec wp2shell, suivent une logique de correctif similaire : mise à jour rapide, puis audit.