Un score maximal sur l’échelle CVSS, un correctif publié en urgence le 7 septembre 2026, et des attaques détectées trois jours avant même que le patch existe. La faille CVE-2026-75650 frappe Adobe Commerce et Magento Open Source, deux briques sur lesquelles tournent des milliers de boutiques en ligne. Le réflexe habituel consiste à déployer le correctif et à considérer le dossier clos. C’est précisément l’erreur à éviter.
CVE-2026-75650 : une faille critique notée 10/10 sur Adobe Commerce
La vulnérabilité appartient à la catégorie CWE-1336, qui désigne une neutralisation incorrecte d’éléments spéciaux dans un moteur de templates. En clair : le système de gabarits de Magento interprète mal certaines propriétés de style, et un attaquant peut détourner ce mécanisme pour injecter son propre code.
Trois éléments expliquent la note de gravité de 10/10 attribuée par Adobe. L’attaque se déclenche à distance par le réseau, elle ne réclame aucune authentification, et elle n’exige aucune action de la part d’un utilisateur ou d’un administrateur. Un serveur exposé qui n’a pas reçu le correctif peut donc être compromis sans qu’un seul identifiant ait circulé.
Le bulletin APSB26-146, publié le 7 septembre 2026, porte la priorité maximale. Le correctif lui-même répond à la référence VULN-39341 et se présente sous plusieurs archives selon la branche installée. Dans une mise à jour du 11 septembre, l’éditeur a précisé que le patch couvrait désormais l’ensemble des versions comprises entre 2.4.4 et 2.4.7, ce qui n’était pas le cas à la publication initiale.
| Produit | Branches affectées | Portée |
|---|---|---|
| Adobe Commerce | 2.4.4 à 2.4.9, versions d’août 2026 et antérieures | Toutes plateformes |
| Adobe Commerce B2B | 1.3.3 à 1.5.3, versions d’août 2026 et antérieures | Toutes plateformes |
| Magento Open Source | 2.4.6 à 2.4.9, versions d’août 2026 et antérieures | Toutes plateformes |
Pour les installations hébergées sur Commerce Cloud, la vérification ne s’arrête pas à la présence du fichier de patch. Adobe recommande de confirmer son application effective via le Quality Patches Tool. Un correctif téléchargé mais inactif laisse la boutique dans la même situation qu’avant l’alerte.
StyleSmuggler : des attaques observées dès le 4 septembre 2026
Sansec, société néerlandaise spécialisée dans la sécurité e-commerce, a baptisé la faille StyleSmuggler et documenté les premières intrusions à partir du 4 septembre 2026. Trois jours séparent donc l’exploitation de la faille de la mise à disposition du correctif, une fenêtre suffisante pour installer durablement une porte dérobée.
La charge déposée utilise un canal de commande et de contrôle qui imite le trafic d’un serveur de temps NTP. Ce détail n’est pas anodin : ce type d’échange se fond dans le bruit réseau et échappe à une lecture rapide des journaux. La compromission laisse pourtant une trace visible sans outil sophistiqué, sous la forme d’emails intitulés « Payment Transaction Failed Reminder » envoyés par des serveurs infectés.
Un second mode opératoire identifié par Sansec
Dans une mise à jour de son rapport, Sansec décrit un second attaquant qui adopte une approche différente. Celui-ci dépose un webshell PHP de 485 octets, chargé de collecter des informations sur le serveur, de tester si le répertoire pub/media est accessible en écriture, puis d’exfiltrer le résultat vers un sous-domaine oast.site.
Cette infrastructure est couramment associée à Interactsh, un outil de test utilisé pour détecter les requêtes sortantes. Le recours à ce type de domaine indique une phase de reconnaissance avant une attaque plus lourde. Deux campagnes distinctes sur la même faille, c’est le signe qu’un correctif de sécurité ne referme pas automatiquement une brèche déjà franchie.
Le CERT-FR a de son côté listé les systèmes concernés : Adobe Commerce, Adobe Commerce B2B et Magento Open Source dès lors qu’ils n’ont pas reçu le correctif. Le périmètre dépasse donc la seule boutique classique et inclut les configurations B2B, souvent moins surveillées.
Pourquoi appliquer le correctif de sécurité ne suffit pas à clore l’incident
La clé de chiffrement de Magento protège des éléments sensibles : jetons d’intégration, identifiants de passerelles de paiement et jetons d’automatisation disposant de privilèges élevés. Adobe insiste sur un point que beaucoup d’équipes négligent : renouveler cette clé ne suffit pas à invalider des identifiants déjà exfiltrés.
La rotation doit se faire à la source, directement chez Stripe, Braintree, Adyen ou PayPal, et pas uniquement dans l’interface Commerce. Sans cette étape, un attaquant qui a copié les clés avant l’application du patch continue de les utiliser sans être inquiété. La procédure complète publiée par Adobe comporte quinze étapes.
Pour une agence qui administre une dizaine de boutiques, cette séquence mobilise plusieurs jours et impose une coordination avec chaque prestataire de paiement. Le précédent observé sur l’échec des mises à jour de sécurité sur WordPress montre la même mécanique : une boutique remise en ligne sans renouvellement complet de ses secrets reste exposée à la faille suivante.
Les contrôles à mener après le correctif, dans le bon ordre
La séquence compte autant que le contenu des vérifications. Chercher un webshell avant d’avoir stabilisé l’environnement revient à fouiller une pièce sans avoir fermé la porte. Voici l’ordre que retiennent les équipes ayant déjà traité ce type d’incident.
- Appliquer le correctif VULN-39341 sur toutes les instances, puis confirmer son activation avec le Quality Patches Tool.
- Rechercher les traces d’intrusion : fichiers PHP suspects, horodatages anormaux dans pub/media, requêtes sortantes vers des domaines inconnus.
- Analyser les journaux réseau à la recherche d’un trafic imitant un serveur NTP vers une adresse externe.
- Vérifier les files d’emails envoyées par le serveur, notamment les notifications de transaction échouée.
- Renouveler les secrets : clé de chiffrement, comptes administrateurs, jetons d’intégration et identifiants API.
- Régénérer les clés chez les prestataires de paiement et les fournisseurs tiers concernés, à la source.
- Documenter chaque action avec son horodatage, pour pouvoir justifier la chronologie en cas de contrôle.
Un point pratique mérite l’attention des responsables techniques : la date du correctif n’a aucune valeur juridique comme point de départ d’une éventuelle notification. Ce qui compte, c’est le moment où l’équipe a eu connaissance d’un indice de compromission sur une installation donnée.
Faille Adobe Commerce et obligation de notification à la CNIL
L’article 33 du RGPD impose au responsable de traitement de notifier une violation à la CNIL dans les 72 heures suivant la prise de connaissance, sauf si le risque pour les personnes concernées est jugé peu probable. Le déclencheur n’est donc pas le 7 septembre, date de publication du patch, mais la date à laquelle une équipe identifie un indice sérieux sur une boutique précise.
Lorsque la violation présente un risque élevé, l’article 34 impose d’informer directement les personnes concernées. Et si l’organisation intervient comme prestataire, l’article 33.2 la place en position de sous-traitant : elle doit alors prévenir son client dans les meilleurs délais, indépendamment de ce que prévoit le contrat.
Ce cadre explique pourquoi la traçabilité des investigations devient un enjeu de protection des données autant qu’un sujet technique. Un rapport d’analyse daté, avec les fichiers examinés et les conclusions, sert autant à l’équipe interne qu’en cas de demande de justification.
Compromission potentielle : le critère qui doit guider la décision
Toute boutique Magento restée exposée entre le 4 et le 7 septembre doit être considérée comme potentiellement compromise tant qu’une vérification n’a pas écarté ce scénario. Le correctif bloque l’exploitation de la faille, mais il ne détecte aucune intrusion antérieure et n’invalide aucun identifiant déjà copié.
La leçon dépasse le cas d’Adobe Commerce. Les incidents récents illustrent une tendance de fond : la cybersécurité assistée par IA accélère la détection comme la découverte de nouvelles failles, et les fenêtres d’exposition se réduisent. Dans ce contexte, la valeur d’une équipe ne se mesure plus à sa vitesse d’application d’un patch, mais à sa capacité à reconstituer ce qui s’est passé avant.
Tant qu’une recherche de webshell n’a pas été menée et que les mots de passe n’ont pas été renouvelés jusqu’au niveau des prestataires de paiement, l’incident reste ouvert. Le correctif ferme la porte ; il ne dit rien de ce qui est déjà entré.
