StyleSmuggler installe une porte dérobée zero-day sur des boutiques Magento pourtant entièrement à jour

Des attaquants exploitent une vulnérabilité non corrigée de Magento Open Source pour exécuter du code à distance sans authentification et installer une porte dérobée Linux persistante. Adobe Commerce pourrait également être exposé, même si ce produit n’a pas encore fait l’objet de tests concluants.

L’entreprise néerlandaise spécialisée dans la sécurité du e-commerce Sansec a baptisé la faille StyleSmuggler et révélé la campagne le 5 septembre 2026, après avoir observé les premières attaques le 4 septembre. Des investigations indépendantes menées par Disrex Group ont confirmé deux compromissions réussies et une tentative d’intrusion.

Au 6 septembre, Adobe n’avait publié ni avis de sécurité, ni identifiant CVE, ni correctif, ni solution de contournement officielle. L’index des bulletins de sécurité d’Adobe Commerce n’avait pas été mis à jour depuis le 11 août.

Les versions actuelles de Magento sont bien vulnérables

Sansec a reproduit l’intégralité de la chaîne d’exploitation sans authentification sur des installations vierges de Magento Open Source :

• 2.4.7
• 2.4.8
• 2.4.9

L’entreprise considère que toutes les versions actuelles de Magento sont concernées, y compris la 2.4.9.

La première victime identifiée utilisait Magento Open Source 2.4.6-p15, avec les mises à jour de sécurité Adobe de juillet et août 2026 installées. Adobe désigne ce niveau de correctif de la branche concernée sous le nom 2.4.6-2026-aug, qui est le plus récent disponible pour la branche 2.4.6.

Disrex a enquêté séparément sur une boutique compromise en 2.4.8 et sur une autre en 2.4.7-p2. Cette dernière accusait huit niveaux de correctifs de retard par rapport à la version alors actuelle, 2.4.7-p10, mais le niveau de mise à jour n’a pas déterminé l’issue de l’attaque : les deux systèmes ont été compromis.

Le périmètre au-delà de Magento Open Source reste incertain. Sansec n’a pas publié de reproduction réussie visant Adobe Commerce ou Adobe Commerce on Cloud, et Adobe n’a pas confirmé les versions concernées.

La prochaine mise à jour de sécurité programmée par Adobe est prévue le 8 septembre, mais on ignore si elle corrigera StyleSmuggler. Au 6 septembre, aucune inscription dans le catalogue des vulnérabilités exploitées connues de la CISA ni aucun délai de remédiation associé n’avaient été signalés.

Le rendu d’e-mails malveillants achève la chaîne d’attaque

StyleSmuggler s’appuie sur deux étapes pour transformer des données écrites lors des opérations courantes de Magento en code PHP exécutable.

Dans un premier temps, l’attaquant injecte du PHP dans un fichier que Magento peut créer ou mettre à jour, comme un fichier de rapport d’erreur. Il déclenche ensuite l’envoi de l’e-mail Magento standard « Payment Transaction Failed Reminder », ce qui amène la plateforme à traiter le fichier empoisonné lors du rendu du message.

Le destinataire n’a pas besoin d’ouvrir l’e-mail. Le code peut s’exécuter même si la remise du message échoue.

Une hausse inhabituelle du nombre de rappels d’échec de paiement doit donc faire l’objet d’une investigation, même si ces messages peuvent également être générés par des transactions légitimement refusées.

L’analyse du code source réalisée par Disrex indique qu’une directive injectée appelle des classes Magento associées au compilateur d’injection de dépendances en ligne de commande. La séquence qui en résulte intègre un chemin de fichier choisi par l’attaquant et pointant vers le fichier empoisonné quelques instants plus tôt.

Les enquêteurs ont associé le point d’entrée présumé à trois fichiers situés sous :

setup/src/Magento/Setup/Module/Di/Code/

Sansec n’a pas confirmé cette interprétation, tandis que Disrex n’a pas publié la requête malveillante complète. L’analyse détaillée de la chaîne d’exploitation, du dropper et de l’implant n’a pas non plus été publiée.

Une fois l’exécution du code réussie, un dropper PHP tente successivement d’utiliser six fonctions de création de processus. Il télécharge ensuite la porte dérobée et la lance.

L’implant se fait passer pour un processus du noyau Linux

Le logiciel malveillant s’exécute en arrière-plan sous le nom de processus trompeur suivant :

[kworker/u:8:0]

Ce libellé imite un thread du noyau Linux. Toutefois, un véritable worker du noyau appartient à root et ne possède pas de mémoire résidente en espace utilisateur. Un processus kworker entre crochets, appartenant au compte du site Magento et consommant de la mémoire, est hautement suspect.

L’implant définit sa ligne de commande sur ce nom entre crochets. Une détection fondée uniquement sur le champ comm du processus peut donc ne pas le repérer.

Le principal emplacement de la charge utile se trouve en dehors de la racine web :

~/.local/share/.gvfsd/gvfsd-user

Disrex décrit cette charge utile comme un exécutable Rust dépouillé et lié statiquement, d’environ 1,9 Mo, avec des versions compilées pour x86-64 et arm64. La persistance est assurée par une entrée cron qui le relance toutes les cinq minutes :

*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user

Une deuxième variante lance une charge utile depuis /tmp/.kw_.

Plutôt que de remplacer la crontab à l’aide de la commande habituelle, le logiciel malveillant écrit directement dans :

/var/spool/cron/crontabs/

Cette technique évite de générer dans les journaux système l’événement attendu de remplacement de la crontab. Une boutique compromise contenait la même ligne malveillante 1 728 fois, et l’implant la rétablissait dans la seconde suivant sa suppression.

D’autres chemins pertinents sont les suivants :

~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
/tmp/.gvfsd_<8hex>.lock
/tmp/.kw_<random><random>

Sur un système, l’exécutable en cours d’exécution différait de la charge utile stockée sur le disque. Les équipes d’intervention doivent donc calculer l’empreinte du fichier ainsi que celle de l’exécutable mappé via :

/proc/<pid>/exe

Deux boutiques ont été compromises avant la mise en place des défenses

Disrex, qui fournit des services d’hébergement Magento sous la marque RexHosting, a confirmé deux compromissions sur des comptes clients isolés.

La première boutique concernée utilisait Magento Open Source 2.4.8 et a été attaquée à 23 h 10 UTC le 4 septembre. Sansec Shield était installé, activé et bloquait les autres flux malveillants, mais les règles propres à StyleSmuggler n’étaient pas encore disponibles.

Une deuxième boutique, en 2.4.7-p2, a été attaquée pour la première fois à 0 h 55 UTC le 5 septembre. Elle n’était pas cliente de Shield. Disrex s’est appuyée sur les éléments récupérés sur ce système pour élaborer son analyse technique et ses règles pour les serveurs web.

Les deux compromissions sont survenues pendant un intervalle d’environ huit heures entre les premières activités observées de la campagne et la disponibilité de protections dédiées.

Les comptes concernés ne disposaient chacun que d’un seul propriétaire de site, sans accès sudo ni possibilité d’atteindre les environnements d’autres clients. Le processus malveillant s’exécutait avec les privilèges limités de l’utilisateur du site. Disrex n’a constaté ni déplacement latéral ni compromission d’autres sites hébergés.

Les deux boutiques ont été confinées le jour de leur découverte, environ onze et quatorze heures après le premier contact. Les sessions ont été invalidées et la rotation des identifiants a commencé par précaution.

Les enquêteurs n’ont trouvé aucun élément attestant :

• Du vol de données
• De skimmers de cartes de paiement
• De comptes administrateur frauduleux
• De portes dérobées dans les bases de données
• D’un déplacement latéral
• De la compromission de sites voisins

Le nombre de boutiques touchées en dehors de ces investigations est inconnu.

La détection doit dépasser la racine documentaire

La vérification de détection initiale de Sansec recherche var/report/ :

X_TRACE_

Cette seule recherche ne suffit pas. Dans les deux infections examinées par Disrex, les attaquants avaient au contraire empoisonné :

var/log/system.log

Le marqueur a également évolué au cours de la campagne. Les premières requêtes utilisaient un en-tête de type X-TRACE- suivi de dix caractères hexadécimaux ; dans les flux ultérieurs, le mot TRACE avait disparu. Les règles de détection doivent reconnaître la structure générale plutôt qu’une chaîne fixe.

Une TypeError indiquant que array_merge() reçoit un entier immédiatement après l’opération d’inclusion concernée révèle une exploitation réussie. Ce comportement n’est toutefois pas systématique : une variante plus discrète renvoie un tableau vide et ne laisse aucune erreur équivalente.

Les indicateurs SHA-256 publiés sont les suivants :

e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7
8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef
251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220

Les indicateurs réseau sont les suivants :

247.cdnflare[.]xyz
99.84.67[.]186:443
88.216.72[.]181
5.181.86[.]133

L’absence de trafic externe ne prouve pas qu’un système est sain. Un implant n’a établi aucune connexion sortante observable, mais a ouvert 28 connexions vers le service Redis de la boutique sur le port 6379 et accédé aux données de session Magento.

Les analyses limitées à la racine documentaire peuvent également donner un faux sentiment de sécurité. Sur une boutique compromise, le scanner a renvoyé un résultat sain alors que le répertoire personnel contenait la charge utile et 1 728 entrées cron malveillantes.

Ce que les opérateurs Magento doivent faire dès maintenant

En l’absence de correctif officiel, les opérateurs doivent combiner une réduction temporaire de l’exposition à des vérifications forensiques au niveau des comptes.

Sansec recommande de désactiver temporairement GraphQL sur les boutiques qui ne bénéficient pas de la protection Shield. Cette mesure peut s’avérer impraticable pour les vitrines headless et les applications web progressives, qui dépendent de GraphQL, alors que les déploiements classiques et Hyvä ne l’utilisent généralement pas.

Disrex, ProxiBlue et Graycore ont publié des mesures d’atténuation non officielles. Le correctif proposé par Disrex empêche trois méthodes du scanner d’injection de dépendances de s’exécuter via HTTP et les limite à une exécution en ligne de commande. Sa version composer-patches s’appliquerait aux versions Magento 2.4.6 à 2.4.9 et résisterait aux déploiements Composer.

Les administrateurs doivent d’abord vérifier la compatibilité. Le paquet tiers mageplaza/module-admin-permissions appelle ClassesScanner.php via HTTP ; cette protection peut donc bloquer son interface d’administration.

Les règles nginx et Apache publiées bloquent les paramètres utilisés dans les attaques observées, mais uniquement lorsqu’ils apparaissent dans la chaîne de requête. Des paramètres équivalents placés dans des corps POST ou JSON parviennent toujours jusqu’à PHP. Ces règles perturbent la campagne actuelle, mais ne corrigent pas la vulnérabilité.

Les équipes d’intervention doivent rechercher des traces dans l’ensemble du compte d’hébergement, notamment dans les répertoires personnels, /tmp, les fichiers de spool cron, var/report/ et var/log/system.log. Elles doivent examiner les processus en cours via /proc, comparer les empreintes en mémoire et sur disque, invalider les sessions Magento et renouveler les identifiants.

Une analyse propre de la vitrine ne suffit pas. Supprimer le binaire visible sans arrêter le processus ni éliminer sa persistance cron ne suffit pas davantage.