Ce que la faille fait vraiment

CVE-2026-71362 est une vulnérabilité d'autorisation incorrecte avec un score CVSS de 9,1 dans Adobe Commerce, Commerce B2B et Magento Open Source. Elle permet à un attaquant non authentifié de basculer la session d'un client vers le compte d'un client différent, donnant à l'attaquant accès à l'historique des commandes, aux adresses enregistrées et aux données de paiement stockées de la victime sans avoir besoin d'un mot de passe, d'un compte propre ni d'aucune interaction de la part de la victime.

Adobe a corrigé la faille dans son cycle Patch Tuesday d'août 2026, aux côtés de six autres problèmes de sécurité dans les trois produits, et a déclaré au moment de l'avis n'avoir aucune preuve que le bug était exploité dans la nature. La société de sécurité Sansec, qui exploite une télémétrie de détection sur une grande partie des boutiques Magento et Adobe Commerce dans le monde, raconte une histoire différente sur ce qui s'est passé ensuite.

Pourquoi elle a été touchée en quelques heures

Sansec affirme que son pare-feu applicatif Shield a commencé à bloquer des tentatives d'exploitation réelles contre CVE-2026-71362 peu après la publication de l'avis d'Adobe -- les attaquants sont passés des notes de correctif à des attaques réelles en quelques heures plutôt qu'en quelques jours. Cet écart entre divulgation et exploitation est désormais la norme pour cette plateforme plutôt que l'exception : Adobe Commerce et Magento ont une longue histoire de failles critiques transformées en armes presque dès que les détails techniques nécessaires à la construction d'un exploit deviennent publics, car le code sous-jacent tourne sur une base installée immense et lente à corriger de boutiques en ligne indépendantes.

Le mécanisme de prise de contrôle de compte lui-même est aussi inhabituellement dangereux pour un bug de couche vitrine : la plupart des vulnérabilités du commerce électronique exigent un point d'appui préalable, mais celle-ci permet à un visiteur totalement anonyme de devenir n'importe quel autre client avec une seule requête forgée, ce qui explique pourquoi Sansec a choisi de publier une signature de détection le jour même plutôt que d'attendre une confirmation plus large.

Ce que les commerçants devraient vérifier dès maintenant

Toute boutique utilisant Adobe Commerce, Commerce B2B ou Magento Open Source devrait confirmer que le correctif de sécurité d'août 2026 est installé, pas seulement programmé, puisque les données de Sansec montrent des tentatives d'exploitation réelles déjà en cours plutôt que théoriques. Comme la faille se situe dans la gestion des sessions plutôt que dans un module isolé, il vaut la peine d'ajouter par-dessus le correctif une règle de pare-feu applicatif qui bloque spécifiquement le schéma d'exploitation connu pendant que le déploiement est vérifié sur chaque instance de boutique, y compris les sites de test et les sites régionaux secondaires que l'on oublie facilement pendant un cycle de correctifs.

Pour les commerçants européens et britanniques en particulier, une faille de prise de contrôle de compte de ce type est aussi une question de notification en matière de protection des données : si l'historique des commandes, les adresses ou les métadonnées de paiement des clients ont été accessibles à un attaquant non authentifié même brièvement, c'est exactement le type d'exposition qu'un délégué à la protection des données doit évaluer par rapport aux seuils de notification des violations, indépendamment du fait que la télémétrie de Sansec montre ou non que votre boutique précise a été touchée.

À lire ensuite: Le sursis NIS2 de l'Allemagne a pris fin  |  361 Serveurs vCenter Touchés Avant l'Entrée en KEV