StyleSmuggler : une faille zero-day sans correctif touche tout Magento et Adobe Commerce

Le spécialiste de la sécurité e-commerce Sansec a documenté une faille zero-day baptisée StyleSmuggler, touchant Magento Open Source et Adobe Commerce. Elle permet une exécution de code à distance sans authentification et l'installation de portes dérobées persistantes.

Trois éléments rendent ce dossier particulièrement sérieux. La faille est déjà exploitée. Toutes les versions actuelles sont concernées, y compris les plus récentes. Et surtout : au moment où nous publions, il n'existe ni identifiant CVE, ni avis de sécurité d'Adobe, ni correctif officiel.

Comment fonctionne l'attaque

L'exploitation se déroule en deux temps, et c'est la seconde étape qui fait l'originalité de StyleSmuggler.

Premier temps : les attaquants injectent du code PHP malveillant dans des fichiers que Magento génère lui-même automatiquement, comme les rapports d'échec de transaction. À ce stade, le code est déposé mais dormant — il attend un déclencheur.

Second temps : ce code s'exécute lorsque Magento envoie un e-mail de relance intitulé « Payment Transaction Failed Reminder ». Aucune interaction de la victime n'est nécessaire ; c'est le fonctionnement normal de la boutique qui arme l'attaque. Le mécanisme détourne les classes du compilateur d'injection de dépendances de Magento pour faire exécuter un chemin de fichier contrôlé par l'attaquant.

Cette conception explique pourquoi la faille est difficile à repérer : à aucun moment un administrateur ne voit une requête suspecte déclencher une exécution. Le dépôt et l'exécution sont dissociés, et le déclencheur est une fonction légitime de la plateforme.

Toutes les versions actuelles sont concernées

Selon The Hacker News, la faille touche l'ensemble des versions actuelles de Magento, confirmée sur les branches 2.4.7, 2.4.8 et 2.4.9.

Un détail mérite d'être souligné, parce qu'il élimine l'explication habituelle. La première victime identifiée faisait tourner la version 2.4.6-p15, avec l'ensemble des correctifs Adobe disponibles déjà appliqués. Autrement dit : cette boutique faisait tout ce qu'on lui demande de faire en matière de mise à jour, et elle a été compromise quand même. Il ne s'agit donc pas d'un défaut de maintenance côté marchand, mais bien d'une faille inédite pour laquelle aucune protection n'existait.

Des compromissions déjà confirmées

Sansec indique avoir observé les premières tentatives d'exploitation dès le 4 septembre 2026. Le groupe Disrex a de son côté documenté deux compromissions confirmées, avec un détail qui en dit long sur le niveau des attaquants : les portes dérobées installées étaient déguisées en threads du noyau Linux, sous des noms de processus imitant ceux du système, pour passer inaperçues dans une liste de processus.

Ce mode opératoire s'inscrit dans une histoire longue. Les boutiques Magento sont depuis des années une cible de choix pour les attaques de type Magecart, qui consistent à injecter dans les pages de paiement un code discret siphonnant les numéros de carte bancaire au moment de leur saisie. Une exécution de code à distance non authentifiée est exactement la porte d'entrée que ce type d'attaque recherche.

Adobe n'avait, au moment de la publication de cet article, publié ni avis de sécurité, ni identifiant CVE, ni correctif. La prochaine publication de correctifs programmée par l'éditeur est fixée au 8 septembre, sans garantie que cette faille y soit traitée.

Mesures d'urgence à appliquer dès maintenant

En l'absence de correctif éditeur, la seule stratégie disponible consiste à réduire la surface d'attaque et à chercher activement des traces de compromission.

• Désactiver temporairement GraphQL jusqu'à la publication d'un correctif officiel.

• Rechercher des marqueurs d'injection PHP suspects dans var/report/ et var/log/system.log.

• Surveiller toute réception ou tout envoi inhabituel d'e-mails « Payment Transaction Failed Reminder » : c'est le déclencheur de l'exécution.

• Désactiver la fonction proc_open() dans la configuration PHP.

• Monter /tmp, /var/tmp et /dev/shm avec l'option noexec, pour empêcher l'exécution de binaires déposés dans ces répertoires.

Si la compromission est avérée

• Changer l'intégralité des identifiants et des clés API, y compris ceux des services tiers connectés à la boutique.

• Vider le stockage des sessions, pour invalider toute session détournée.

• Rechercher un processus [kworker/u:8:0] appartenant à un utilisateur non root — un nom de thread noyau légitime ne devrait jamais tourner sous un autre compte.

• Inspecter le répertoire ~/.local/share/.gvfsd/, utilisé pour dissimuler des fichiers de porte dérobée.

Source

The Hacker News, d'après les recherches de Sansec — « Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores »