La faille zero-day StyleSmuggler permet aux attaquants de prendre le contrôle à distance de boutiques Magento pourtant corrigées

Une vulnérabilité jusque-là inconnue, baptisée StyleSmuggler, fait actuellement l’objet d’attaques contre des boutiques Magento et Adobe Commerce, y compris des systèmes ayant installé les dernières mises à jour de sécurité.

L’attaque permet l’exécution de code à distance sans authentification en exploitant le traitement des modèles et la gestion liée à GraphQL de Magento. Les intrusions réussies ont installé une porte dérobée Linux basée sur Rust et, dans certains cas, un web shell PHP dissimulé.

SecurityAffairs a détaillé publiquement cette campagne le 7 septembre 2026, en attribuant l’analyse technique à Sansec. Les premières tentatives d’exploitation observées remontent au 4 septembre.

Aucun identifiant CVE, score CVSS ni niveau de gravité officiel d’Adobe n’a été communiqué. On ignore également si la vulnérabilité figure dans le catalogue des vulnérabilités exploitées connues de la Cybersecurity and Infrastructure Security Agency des États-Unis.

Les boutiques à jour et exécutant la dernière version restent exposées

StyleSmuggler affecte Magento Open Source et Adobe Commerce, mais aucune matrice officielle des versions concernées n’est encore disponible.

Sansec a reproduit l’exploit sur des installations vierges et identifié une première victime utilisant Magento 2.4.6-p15, avec les mises à jour de sécurité de juillet et août 2026 installées. Les versions actuelles de Magento Open Source explicitement identifiées comme vulnérables sont les suivantes :

• Magento Open Source 2.4.7
• Magento Open Source 2.4.8
• Magento Open Source 2.4.9

Une autre analyse indique que toutes les versions de Magento et d’Adobe Commerce sont vulnérables. Tant qu’Adobe n’aura pas publié d’avis de sécurité, les administrateurs ne doivent pas considérer comme sûre une version ancienne, récente ou entièrement corrigée.

L’exposition est considérable. Magento serait utilisé par plus de 160 000 sites web, dont environ 14 000 figurant parmi les un million de sites les plus fréquentés. Une compromission côté serveur peut mettre à la portée d’un attaquant les données clients, les identifiants d’administration, les jetons d’API, les secrets des prestataires de paiement, les mots de passe des bases de données et les clés d’accès au cloud.

Adobe préparait apparemment un correctif. Une mise à jour de sécurité était attendue le 8 septembre, mais on ignorait si elle intégrerait un correctif pour StyleSmuggler.

Une notification de paiement échoué déclenche l’exécution

L’exploit cible la chaîne de rendu des modèles de Magento. Il injecte du PHP en exploitant le traitement associé à la propriété styles et à GraphQL, en contournant les contrôles censés bloquer le contenu dangereux dans les modèles.

La chaîne d’attaque observée comporte deux étapes principales. Dans un premier temps, un attaquant non authentifié crée ou empoisonne un enregistrement Magento contenant du code PHP malveillant. Une méthode démontrée consiste à générer un rapport de paiement échoué.

Magento génère ensuite sa notification standard Payment Transaction Failed Reminder. Au cours de cette opération, la plateforme évalue le contenu empoisonné et exécute le code PHP intégré sur le serveur.

Aucun client ni administrateur n’a besoin d’ouvrir une pièce jointe ou de suivre un lien. L’exploit peut réussir même si l’e-mail de notification n’est jamais envoyé, car l’exécution intervient pendant le rendu côté serveur de Magento.

Une hausse inexpliquée du nombre de rappels de paiements échoués peut donc signaler une exploitation. Elle ne constitue toutefois pas une preuve définitive, puisque de véritables échecs de paiement génèrent le même type de notification.

Modifier le backend de session de Magento ne suffit pas à bloquer l’attaque de manière fiable. Lors d’un incident, une tentative exploitant le stockage des sessions a échoué. Huit secondes plus tard, le même opérateur s’est rabattu sur un fichier téléversé via la fonctionnalité d’options personnalisées de Magento et a réussi à exécuter du code.

Ce changement rapide laisse penser que les attaquants adaptent activement leurs méthodes de dépôt. Les défenses reposant sur un seul emplacement de charge utile ou sur un modèle d’attaque théorique ne devraient donc pas suffire.

Une porte dérobée Rust se dissimule derrière des noms de processus Linux et du trafic NTP

Les attaques réussies ont déployé un implant Linux compact basé sur Rust. Le malware s’exécute en arrière-plan, se connecte à une infrastructure contrôlée par l’attaquant et attend des commandes.

Aucune commande ultérieure provenant de l’implant n’avait été observée au moment de la publication des résultats. Toutefois, un hôte exécutant cette porte dérobée doit être considéré comme compromis, puisque l’opérateur conserve la capacité d’exécuter des commandes à distance.

Le malware a changé de stratégie d’usurpation du nom de processus selon les échantillons :

• Un premier échantillon apparaissait sous le nom [kworker/u:8:0]
• Une variante observée le 6 septembre utilisait fc-cache
• Un échantillon observé le 7 septembre utilisait chronyd

Ces noms imitent respectivement un processus de travail du noyau, l’utilitaire Linux de cache des polices et un démon courant de synchronisation de l’heure. Le nom d’un processus ne suffit pas à distinguer l’implant d’un logiciel légitime.

La version utilisant fc-cache se copiait dans ~/.cache/fontconfig/fc-cache, créait un fichier de verrouillage PID et mettait en place une persistance via cron. Sa tâche planifiée relançait l’implant toutes les 30 minutes.

D’autres versions employaient des mécanismes de persistance différents. Une variante de chronyd s’appuyait sur cron, tandis qu’une autre se relançait sans laisser d’entrée cron visible. Un crontab vide ne permet donc pas de conclure qu’un serveur est sain.

Les premiers échantillons communiquaient via TLS et WebSockets. Les versions plus récentes dissimulent le trafic de commande et de contrôle sous la forme d’activité du Network Time Protocol en envoyant des paquets UDP vers le port 123.

L’implant résout ntp.timesync.to toutes les 60 secondes et transmet des paquets de 48 octets qui ressemblent à des réponses de serveurs NTP. Seuls les quatre premiers octets suivent une structure conventionnelle de type NTP. Le reste des données peut contenir l’identifiant de l’implant, le nom d’hôte, le nom d’utilisateur, la version du système d’exploitation, la durée de fonctionnement, l’utilisation de la mémoire et du disque, le statut root et la version du malware.

Les domaines observés étaient associés à 185.157.160.251 le 7 septembre. La porte dérobée peut également interroger ipify, icanhazip, ident.me et ipinfo.io afin de déterminer l’adresse IP publique du serveur.

Avant d’émettre ses signaux, elle vérifie la valeur TracerPid de Linux pour détecter d’éventuelles opérations de débogage ou de traçage. Si une trace est détectée, le malware s’installe tout de même, mais désactive ses communications réseau.

Un second opérateur dissimule un web shell dans les répertoires de cache des images

Les enquêteurs ont également découvert les indices d’un opérateur apparemment distinct, qui exploitait des boutiques compromises. Cet acteur a installé un petit dropper PHP qui écrivait un web shell dans le cache des images de produits de Magento.

Le shell était placé dans des répertoires aux noms ressemblant à des hachages, ce qui l’aidait à se fondre dans le contenu généré du cache. En temps normal, il renvoyait une réponse 404 d’apparence ordinaire.

La fonctionnalité malveillante n’était activée que lorsqu’une requête fournissait l’en-tête X-Cache-Token approprié. Le shell exécutait alors le code PHP transmis via un paramètre POST.

Avant d’installer le shell, le dropper contactait :

457cfa2fb7p5.daf892t5qau4og8pi4cghbc6fhm1dim3u.oast.site

Cette adresse appartient à un service public de test hors bande couramment utilisé pour confirmer l’exécution d’un code injecté. La charge utile récupérée provenait d’un en-tête de requête Magento Store, tandis que ses balises PHP restaient échappées au format JSON dans l’enregistrement stocké par Magento.

La suppression d’un processus Rust visible ne suffit donc pas. Un serveur touché peut également contenir des enregistrements modifiés, des modèles empoisonnés, des charges utiles téléversées, une persistance via cron et des shells PHP dissimulés dans des emplacements de cache ou de stockage accessibles en écriture.

Les indicateurs que les défenseurs doivent rechercher dès maintenant

Les opérateurs Magento doivent corréler les données de télémétrie applicatives, système, DNS et réseau plutôt que de s’appuyer sur un seul indicateur. Les vérifications prioritaires sont les suivantes :

• Hausses soudaines de l’activité Payment Transaction Failed Reminder
• Balises PHP ou balises PHP échappées au format JSON inattendues dans les enregistrements Magento
• Modèles modifiés, rapports suspects et téléversements inhabituels via les options personnalisées
• Processus nommés [kworker/u:8:0], fc-cache ou chronyd s’exécutant depuis des chemins inhabituels
• Le fichier ~/.cache/fontconfig/fc-cache
• Tâches cron exécutant des binaires suspects toutes les 30 minutes
• Messages répétés crontab: command not allowed associés à des comptes tels que www-data
• Fichiers PHP présents sous pub/media, notamment dans les répertoires du cache des images de produits
• Requêtes contenant l’en-tête X-Cache-Token
• Requêtes DNS pour ntp.timesync.to
• Connexions impliquant 185.157.160.251
• Trafic UDP/123 sortant inattendu ou paquets de type NTP de 48 octets
• Le domaine OAST indiqué dans les journaux Magento, des serveurs web, du DNS ou des proxy

Un processus chronyd d’apparence légitime qui émet neuf paquets rapides en mode serveur NTP chaque minute est particulièrement suspect. Les administrateurs doivent comparer ce trafic aux sources de temps configurées sur l’hôte et à son comportement habituel de synchronisation.

Les indicateurs peuvent évoluer rapidement. Entre le 6 septembre et le 7 septembre, la campagne a déjà changé de noms de processus, de techniques de persistance et de vecteurs d’exploitation.

Désactiver GraphQL si possible et considérer les détections comme une compromission

Tant qu’Adobe n’aura pas publié de correctif officiel et que les administrateurs ne l’auront pas appliqué, Sansec recommande de désactiver temporairement GraphQL lorsque cela est possible sur le plan opérationnel. Cette mesure peut perturber des fonctionnalités de la boutique ou des intégrations externes. Les organisations doivent donc en tester les effets et envisager des mesures compensatoires lorsqu’il est impossible de désactiver GraphQL.

Les équipes doivent inspecter les répertoires Magento accessibles en écriture, les fichiers de spoule cron, les arborescences de processus, les journaux d’authentification, les journaux des serveurs web, l’historique DNS et le trafic UDP/123 sortant. La découverte d’un indicateur StyleSmuggler doit entraîner l’isolement de l’hôte et la préservation des éléments nécessaires à l’analyse forensique.

La réponse à incident doit également prévoir la rotation des mots de passe des administrateurs Magento, des jetons d’API, des identifiants de base de données, des secrets des prestataires de paiement et des clés cloud accessibles depuis le serveur. Avant de rétablir le service, les intervenants doivent rechercher d’autres web shells, des enregistrements malveillants, des modèles modifiés, des exécutables téléversés et des mécanismes de persistance en dehors de cron.

Le fait d’exécuter une version à jour ne protège pas contre cette campagne. Tant qu’un correctif vérifié ne sera pas disponible, les systèmes Magento et Adobe Commerce exposés doivent être surveillés comme potentiellement vulnérables. Les systèmes présentant des indicateurs associés doivent, eux, être traités comme déjà compromis.