Magento StyleSmuggler est un zero-day Adobe Commerce et Magento Open Source activement exploité. Adobe l’identifie comme CVE-2026-75650, une faille critique d’exécution de code non authentifiée avec un score CVSS de 10.0. Si vous exploitez une boutique concernée, appliquez dès maintenant le correctif VULN-39341 d’Adobe, faites tourner les clés de chiffrement et les identifiants, puis recherchez toute persistance. Le fait d’appliquer le correctif seul peut combler la faille, mais cela ne supprimera pas une porte dérobée déjà implantée.
Magento StyleSmuggler : la version d’urgence
L’intention de recherche ici est opérationnelle, pas académique. Vous essayez probablement de répondre rapidement à trois questions : suis-je concerné, que dois-je faire en premier, et comment savoir si la boutique est propre ?
Adobe a publié le bulletin APSB26-146 le 7 septembre 2026, en désignant Magento StyleSmuggler comme CVE-2026-75650. La faille est classée comme CWE-1336, neutralisation incorrecte dans un moteur de templates, et Adobe lui a attribué la priorité 1 car l’exploitation est en cours dans la nature contre des marchands Commerce.
Sansec a signalé les premières attaques le 4 septembre 2026 et a décrit publiquement la campagne le 5 septembre. BleepingComputer, SecurityWeek et The Hacker News ont également signalé une exploitation active, BleepingComputer et SecurityWeek indiquant que les attaquants ont déployé des portes dérobées persistantes Linux/Rust après la compromission.
Ne considérez pas cela comme un avis normal de type « appliquer le correctif pendant la prochaine fenêtre ». Une faille d’exécution de code côté serveur sans authentification dans une pile ecommerce exposée aux paiements est à peu près ce qu’il y a de pire. Si votre tunnel de commande est en ligne, votre fenêtre de risque est ouverte.
Qui est concerné, et quelles versions sont répertoriées ?
Adobe indique que le problème affecte Adobe Commerce, Adobe Commerce B2B et Magento Open Source sur toutes les plateformes. Ses directives de base de connaissances du 9 septembre 2026 listent Adobe Commerce 2.4.9-2026-aug jusqu’à 2.4.4-2026-aug et antérieures, ainsi que les versions correspondantes de Magento Open Source et B2B.
Pour Magento Open Source, la liste des versions affectées d’Adobe inclut 2.4.9, 2.4.8, 2.4.7 et 2.4.6-2026-aug et antérieures. Pour Adobe Commerce B2B, elle inclut 1.5.3, 1.5.2, 1.4.2, 1.3.4 et 1.3.3-2026-aug et antérieures.
Un cas limite particulièrement problématique : Sansec a signalé que la première victime connue exécutait 2.4.6-p15 avec les correctifs de juillet et août 2026 appliqués et un security:patch-status. En clair, être « entièrement corrigé » avant APSB26-146 n’a pas protégé cette boutique.
| Objet | Statut en 2026 | Pourquoi c'est important |
|---|---|---|
| CVE | CVE-2026-75650 | Identifiant d’Adobe pour StyleSmuggler |
| Gravité | Score CVSS 3.1 de 10.0 | Niveau critique maximal |
| Authentification | Aucune requise | Les attaquants n’ont pas besoin d’un compte administrateur |
| Priorité Adobe | Priorité 1 | Adobe exige l’application urgente du correctif |
| Exploitation observée | À partir du 4 septembre 2026 | Des attaques réelles ont précédé le correctif d’urgence d’Adobe |
| Correctif nommé par Adobe | Correctif d’urgence VULN-39341 | Correctif d’urgence approprié à la version requis |
Sansec indique également avoir reproduit l’ensemble de la chaîne d’exploitation non authentifiée sur des installations propres de Magento Open Source 2.4.7, 2.4.8 et 2.4.9. Cette affirmation provient des recherches de Sansec, et non du bulletin d’Adobe, mais elle est pertinente sur le plan opérationnel, car il s’agit de branches couramment utilisées sur le terrain.
Comment l’exploit fonctionne, en langage opérationnel
Sansec affirme que Magento StyleSmuggler abuse du système de modèles de Magento en injectant du code PHP via les propriétés styles . Le code empoisonné est ensuite exécuté via un chemin d’e-mail d’échec de paiement, ce qui explique l’un des signes les plus étranges signalés par les défenseurs : des hausses inattendues des e-mails Magento « Payment Transaction Failed Reminder ».
Ce détail est important pour le triage. Une boutique peut sembler normale depuis le frontend alors que le modèle et le chemin d’e-mail sont utilisés comme voie d’exécution. Si votre seul contrôle d’état est « les clients peuvent-ils naviguer et payer ? », vous passez à côté de la partie qui intéresse les attaquants.
Avant qu’Adobe ne publie le correctif d’urgence, Sansec, BleepingComputer et The Hacker News mentionnaient un confinement temporaire en désactivant GraphQL lorsque cela était possible. Après le 7 septembre 2026, Adobe et Sansec ont modifié leurs recommandations : appliquez VULN-39341 au lieu de vous fier uniquement au blocage ou à la désactivation de fonctionnalités.
Un écueil mérite davantage d’attention. Sansec indique que déplacer les sessions vers Redis ou un stockage en base de données n’arrête pas l’attaque, et a signalé qu’un opérateur est passé à un fichier téléversé via les options personnalisées de Magento après l’échec d’une tentative liée au stockage des sessions. En d’autres termes, la voie de l’attaquant peut s’adapter pour contourner une atténuation étroite.
Si vous examinez une exposition plus large, comparez cela à d’autres événements de correctifs d’urgence tels que le schéma de réponse au zero-day de PaperCut: l’échec le plus fréquent n’est pas l’absence de correctif, mais le fait de supposer que le correctif efface aussi l’intrus.
Appliquez le correctif d’Adobe, puis immobilisez les éléments en mouvement
La séquence de remédiation d’Adobe du 9 septembre 2026 est précise. Appliquez le correctif VULN-39341 approprié à la version, activez le mode maintenance, désactivez l’exécution de cron, faites une rotation des clés de chiffrement, faites une rotation de tous les mots de passe Admin, désactivez ou régénérez les jetons d’intégration REST, SOAP et GraphQL, et faites une rotation des secrets client OAuth.
Suivez attentivement la séquence. Cron n’est pas un détail secondaire ici, car Sansec a observé une persistance via des entrées cron, y compris une variante fc-cache s’exécutant deux fois par heure à 13,43 * * * *. Si cron continue de s’exécuter pendant le nettoyage, vous risquez de courir après l’implant sur votre propre serveur.
- Identifiez la version exacte d’Adobe Commerce, Commerce B2B ou Magento Open Source et sélectionnez le correctif VULN-39341 correspondant dans les recommandations d’Adobe.
- Mettez la boutique en mode maintenance pendant la fenêtre de réponse, surtout si des identifiants de paiement ou d’administration peuvent être exposés.
- Désactivez l’exécution de cron avant de faire une rotation des secrets ou de supprimer des tâches suspectes.
- Appliquez le correctif et vérifiez l’état du patch avec les outils habituellement utilisés par votre déploiement.
- Faites une rotation de la clé de chiffrement de Commerce, de tous les mots de passe Admin, des jetons d’API, des secrets client OAuth, ainsi que des identifiants de paiement en amont ou de tiers.
- Analysez l’hôte, l’arborescence de l’application, les rapports et les crontabs à la recherche d’indicateurs avant de relancer les tâches planifiées.
Voici le calcul que de nombreux marchands évitent : même une pause d’urgence de deux heures du checkout peut coûter moins cher qu’une semaine de commandes compromises. Si une boutique réalise $120,000 par jour, deux heures d’indisponibilité représentent environ $10,000 d’exposition en chiffre d’affaires brut ; une compromission authentifiée de la passerelle de paiement, une mission d’investigation forensique, la gestion des rétrofacturations et les notifications aux clients peuvent rapidement dépasser ce montant. Vos chiffres seront différents, mais le calcul plaide en faveur d’une interruption contrôlée plutôt que d’un nettoyage à l’aveugle.
Pour une réflexion sur le nettoyage spécifique aux paiements, les conseils pratiques dans contrôles des paiements en ligne sécurisés s’appliquent ici : effectuez la rotation à la source, pas seulement dans l’application e-commerce qui a stocké le secret.
Recherche de portes dérobées après Magento StyleSmuggler
La mise à jour de Sansec du 9 septembre est sans détour : appliquer le correctif ferme la vulnérabilité, mais ne nettoie pas les boutiques déjà compromises. Une restauration depuis une sauvegarde seule peut également manquer des mécanismes de persistance si l’attaquant a implanté des tâches cron, des binaires cachés, des modèles modifiés ou des identifiants qui fonctionnent encore ailleurs.
Commencez par les indicateurs publiés par Sansec. Recherchez des processus ou fichiers suspects nommés [kworker/u:8:0], fc-cache, et chronyd lorsqu’ils ne correspondent pas aux chemins et au comportement attendus par le système d’exploitation. Vérifiez la présence de fichiers ou de processus sous ~/.local/share/.gvfsd/, ~/.cache/fontconfig/fc-cache, /tmp/.kw_*, /tmp/.cache_*, /tmp/.gvfsd-*, /tmp/.fc-*/fc-cache, /tmp/fc-cache, et /tmp/.chrony-*/chronyd.
Les rapports Magento méritent également votre attention. Sansec recommande de vérifier les entrées x_trace_ dans var/report/. Des pics inattendus d’e-mails de rappel de paiement échoué sont un autre indice, surtout s’ils ont commencé entre le 4 septembre et le 7 septembre 2026.
La télémétrie réseau peut être utile, mais ne vous fiez pas à une seule adresse IP. Sansec a signalé une adresse IP de commande et de contrôle comme étant 99.84.67.186, et a indiqué qu’une variante ultérieure fc-cache utilisait un trafic NTP de type UDP/123 vers des domaines incluant ntp.timesync.to, ntp.timesysnc.net, ntp.synctime.to, et ntp.syncstime.to, résolvant au 7 septembre vers 185.157.160.251.
BleepingComputer a signalé que le malware vérifie Linux TracerPid pour détecter le traçage et s’installe quand même, mais n’émet pas de beacon si le traçage est actif. C’est un avertissement utile pour les défenseurs : une exécution silencieuse en sandbox ne prouve pas que le binaire est inoffensif.
Si vous disposez d’une couverture SIEM, c’est le moment où elle démontre sa valeur. Corrélez les requêtes web, les événements e-mail Magento, les modifications de cron, la création de processus, le trafic UDP/123 sortant et les connexions d’administration ; une introduction à la détection des menaces par SIEM est pertinente, car l’examen d’un seul journal est peu efficace contre ce type de compromission en plusieurs étapes.
La rotation des identifiants va bien au-delà de l’admin Magento
Adobe avertit que la clé de chiffrement Commerce peut protéger les jetons d’intégration, les identifiants de passerelle de paiement et les jetons d’automatisation privilégiés. Faire tourner uniquement la clé de chiffrement n’invalide pas les identifiants déjà exposés ; vous devez donc aussi les faire tourner au niveau de la passerelle de paiement ou de la source tierce.
Honnêtement, c’est là que beaucoup de remédiations échouent. Les équipes changent les mots de passe de l’admin Magento, ont l’impression d’être productives, et laissent en circulation une clé API PSP, un jeton ERP, un secret d’intégration d’expédition ou un identifiant d’automatisation toujours valides.
Régénérez les jetons d’intégration REST, SOAP et GraphQL. Faites tourner les secrets client OAuth. Modifiez tous les mots de passe Admin, pas seulement celui du compte super-admin le plus évident. Vérifiez ensuite si un utilisateur d’intégration dispose de plus d’autorisations que nécessaire ; la vérification de confiance et le principe du moindre privilège sont utiles ici, car les intégrations ecommerce accumulent souvent des accès dangereux au fil des ans.
Qu’en est-il des anciennes branches ? Sansec indique qu’Adobe ne publie aucun correctif Magento StyleSmuggler pour Magento/Commerce 2.2, 2.3 ou 2.4.0 à 2.4.3, car ces branches ne sont plus prises en charge. Il indique également que Scandiweb a rétroporté des correctifs vers 41 versions plus anciennes, de 2.2.0 à 2.4.3-p3, mais que Sansec n’avait pas examiné ces correctifs au 9 septembre 2026.
Mon avis : exécuter une branche Commerce non prise en charge pendant un incident CVSS 10.0 activement exploité n’est pas un problème de maintenance, c’est une décision de risque métier. Un rétroportage peut faire gagner du temps, selon son auteur et la façon dont il a été testé, mais cela ne devrait pas devenir le plan à long terme.
Que dire aux clients, à la finance et à l’entreprise
Les équipes de sécurité veulent souvent de la certitude avant de s’exprimer. L’ecommerce ne vous offre pas toujours ce luxe. Si des indicateurs suggèrent une compromission, préservez les journaux, impliquez la réponse à incident et informez tôt la finance et le support client afin qu’ils sachent quelles questions sur les paiements, les remboursements et les comptes peuvent arriver.
N’exagérez pas ce que vous savez. Un serveur corrigé signifie que le point d’entrée connu est fermé ; cela ne prouve pas que les données de commande, les jetons, les sessions d’administration ou les intégrations de paiement n’ont pas été touchés. La formulation prudente est : “nous avons appliqué le correctif d’urgence d’Adobe et nous finalisons l’évaluation de la compromission ainsi que la rotation des identifiants.”
Tenez un journal de décision daté. Notez quand vous avez appliqué VULN-39341, quand le mode maintenance a commencé et s’est terminé, quelles clés ont été renouvelées, quelles entrées cron ont été supprimées, quels indicateurs ont été vérifiés et qui a approuvé la remise en service du paiement. Lors d’une réponse chaotique à Magento StyleSmuggler, ce journal devient votre mémoire.
Les attaquants apprécient aussi les chaînes d’approvisionnement logiciel et les chemins de mise à jour. Si vous auditez donc la confiance du déploiement après l’incident, l’analyse de comment le détournement BGP peut empoisonner les mises à jour constitue une lecture connexe utile. Technique différente, même leçon : ne supposez pas que le chemin qui livre le code est automatiquement digne de confiance.
FAQ
Qu’est-ce que Magento StyleSmuggler ?
Magento StyleSmuggler est le nom utilisé pour CVE-2026-75650, une vulnérabilité critique d’Adobe Commerce et de Magento Open Source divulguée par Adobe le 7 septembre 2026. Elle permet l’exécution de code arbitraire sans authentification et est exploitée activement dans la nature.
Adobe a-t-il un correctif pour Magento StyleSmuggler ?
Oui. Adobe a publié le correctif VULN-39341 le 7 septembre 2026 et a mis à jour ses instructions dans la base de connaissances Commerce le 9 septembre avec la correspondance des versions et les étapes de rotation après correctif.
La désactivation de GraphQL suffit-elle à stopper l’attaque ?
Non. Avant le correctif rapide d’Adobe, la désactivation de GraphQL était citée comme une mesure de confinement temporaire lorsque cela était possible sur le plan opérationnel. Après que VULN-39341 est devenu disponible, Adobe et Sansec recommandent d’appliquer le correctif rapide et de terminer le nettoyage plutôt que de compter uniquement sur le blocage.
Puis-je simplement restaurer ma boutique Magento à partir d’une sauvegarde ?
Non, pas en toute sécurité à lui seul. Sansec avertit que l’application d’un correctif ou la restauration ne supprime pas les implants existants, la persistance via cron, les identifiants volés ou les portes dérobées secondaires, vous devez donc toujours effectuer des vérifications forensiques et faire une rotation des identifiants.
Les boutiques Magento 2.2 et 2.3 sont-elles couvertes par le correctif d’Adobe ?
Sansec indique qu’Adobe ne publie pas de correctif StyleSmuggler pour Magento/Commerce 2.2, 2.3 ou 2.4.0–2.4.3, car ces branches ne sont plus prises en charge. Si vous en utilisez une, considérez la migration ou le rétroportage examiné de manière indépendante comme une mesure urgente de gestion des risques.
FR 
EN 
ES