StyleSmuggler exécute du code sans authentification sur toutes les versions de Magento et d’Adobe Commerce

4 septembre 2026, 22 h 20 UTC. La première exploitation confirmée de StyleSmuggler touche une boutique Magento. 5 septembre 2026. Sansec publie l’analyse du zero-day — avant Adobe, au motif que « des boutiques sont compromises en ce moment même ». 8 septembre 2026. Prochaine publication de correctifs de sécurité Adobe, sans garantie qu’elle couvre la faille. Pourquoi c’est important : l’attaque s’exécute sans authentification, toutes les versions actuelles sont concernées, et la seule parade immédiate hors produit tiers est de couper GraphQL.

Une chaîne gadget à deux temps dans le moteur de templates

StyleSmuggler injecte du code malveillant dans le moteur de templates de Magento en exploitant les propriétés styles pour contourner les garde-fous existants. Le nom dit l’essentiel : le code est « passé en contrebande » à travers le système de styles, là où l’éditeur ne s’attend pas à trouver du PHP exécutable.

La chaîne fonctionne en deux temps. D’abord, l’attaquant empoisonne le code PHP — par exemple en provoquant la génération d’un rapport d’échec qui embarque la charge utile. Ensuite, il laisse Magento exécuter lui-même le code empoisonné lors du rendu d’un e-mail d’échec de paiement. Le déclencheur est le message standard « Payment Transaction Failed Reminder » : personne n’a besoin d’ouvrir l’e-mail, car le code s’exécute pendant que Magento le génère. L’attaque aboutit même si l’envoi échoue — ne pas recevoir le message ne signifie pas que la boutique est saine.

Sansec a reproduit la chaîne complète sans authentification sur des installations propres de Magento Open Source 2.4.7, 2.4.8 et 2.4.9. La première victime tournait sous 2.4.6-p15 avec les correctifs de juillet et août 2026 appliqués, soit le niveau de patch le plus récent de cette branche. Conclusion sans ambiguïté : être à jour ne protège pas.

Un implant qui se fait passer pour un thread noyau

Une fois le code exécuté, l’attaquant installe un backdoor persistant. Sansec le décrit comme un processus d’arrière-plan déguisé sous le nom [kworker/u:8:0] — celui d’un thread du noyau Linux — avec un binaire installé hors de la racine web, sous ~/.local/share/.gvfsd/gvfsd-user dans le répertoire personnel de l’utilisateur du site. Une entrée cron le relance toutes les cinq minutes.

Le prestataire Disrex Group, intervenu sur deux boutiques compromises le 5 septembre, précise la nature du binaire : un programme Rust dépouillé, lié statiquement, d’environ 1,9 Mo, compilé pour x86-64 et arm64. L’entrée cron est écrite directement dans le fichier spool /var/spool/cron/crontabs/, si bien que les journaux système ne montrent aucun remplacement de crontab. Sur une boutique, la même ligne figurait 1 728 fois, et l’implant la ré-ajoutait moins d’une seconde après sa suppression.

Sur l’une des deux boutiques, l’implant n’établissait aucune connexion sortante : il maintenait 28 connexions vers l’instance Redis locale (port 6379) et y lisait le stockage de sessions de Magento. Un comportement discret, collé au trafic interne légitime, qui échappe aux règles réseau classiques de détection d’exfiltration.

GraphQL est la surface, pas la cause

Le vecteur d’exploitation passe par GraphQL — les tentatives capturées incluent des requêtes POST /graphql?styles[…]=. Sansec recommande donc, pour les boutiques sans son produit Shield, de désactiver GraphQL jusqu’à la publication d’un correctif par Adobe. Disrex nuance : les vitrines headless et PWA dépendent de GraphQL, tandis que la plupart des vitrines classiques et Hyvä s’en passent.

La précision compte. GraphQL n’est pas la vulnérabilité — c’est la surface par laquelle la charge utile atteint le moteur de templates. Le couper réduit l’exposition sans traiter la cause racine, qui restera présente tant qu’Adobe n’aura pas corrigé le contournement des styles. Pour une boutique dont le chiffre d’affaires dépend d’une vitrine headless, la décision n’est donc pas triviale : couper GraphQL, c’est parfois couper la boutique.

Corriger avant le bulletin du 8 septembre

Le calendrier est le nœud du problème. Adobe n’a publié ni avis, ni CVE, ni correctif, ni contournement officiel au 5 septembre, et son index de bulletins de sécurité Adobe Commerce ne liste rien depuis la mise à jour du 11 août. Le prochain bulletin est programmé le 8 septembre, sans garantie qu’il couvre cette faille.

En attendant, la marche à suivre est concrète. Désactivez GraphQL si votre vitrine le permet, sinon déployez une protection en périphérie capable de bloquer les requêtes de type styles[…]. Lancez un scan de compromission — eComscan 1.9.7 termine notamment les processus [kworker/u:8:0] résiduels. Vérifiez la présence des indicateurs : l’hôte de téléchargement 247.cdnflare.xyz, les serveurs C2 99.84.67.186 et windwsecurity.run en WebSocket over TLS, ou encore le trafic déguisé en NTP vers ntp.timesysnc.net, time.microsft.run et pool.microsft.studio.

# Vérifier l'implant déguisé en thread noyau
crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ /tmp/.kw_* /tmp/.gvfsd-* 2>/dev/null
ps -eo pid,comm,args | grep -i kworker
grep -rl 'X_TRACE_' var/report/

Enfin, Sansec recommande de pivoter les identifiants Magento si un processus suspect est apparu — même sans preuve que le backdoor a été utilisé, une compromission antérieure aux règles de blocage peut avoir laissé des accès dormants. Un correctif communautaire est déjà référencé par graycoreio pour les équipes qui veulent une mitigation en attendant Adobe.

L’absence de CVE complique la détection automatique

Le fait qu’Adobe n’ait pas encore attribué de CVE a une conséquence concrète pour les défenseurs : les scanners de vulnérabilités, les flux NVD et les outils de gestion de parc ne connaissent pas StyleSmuggler. Une boutique parfaitement à jour — au sens des bulletins publiés — apparaît « saine » alors qu’elle est exploitable. La détection doit donc reposer sur le comportement, pas sur une signature : présence d’un processus [kworker/u:8:0], entrée cron gvfsd, binaire inhabituel sous ~/.local/share/.gvfsd/, ou une vague soudaine d’e-mails « échec de paiement ».

C’est le même aveuglement que les défenseurs ont connu avec d’autres zero-day publiés avant leur CVE : la fenêtre entre l’exploitation active et la disponibilité d’une signature est précisément celle où les équipes doivent scanner « à la main ». Les indicateurs publiés par Sansec et Disrex — hôtes, empreintes sha256, motifs de requêtes — sont, en attendant, la seule base de détection fiable.

Une série de précédents : CosmicSting, PolyShell, SessionReaper

StyleSmuggler n’est pas un accident isolé dans l’écosystème Magento. La plateforme concentre depuis des années l’attention des groupes spécialisés dans le skimming et l’exfiltration de données de paiement : CosmicSting (une chaîne d’injection XML exploitée en masse début 2024), PolyShell (un upload de fichier non restreint qui a frappé 471 boutiques en une heure) et SessionReaper (une RCE sans authentification, référencée CVE-2025-54236) ont tous été documentés par Sansec. La constance du ciblage n’est pas anecdotique : une boutique Magento traite directement les numéros de carte et les données client, ce qui en fait une cible plus rentable que la plupart des applications web.

Cette histoire conditionne la réponse. Les équipes qui gèrent des boutiques Magento devraient déjà disposer de procédures d’incident pour ce type d’implant : pivot des crédentials, revue des tâches cron, comparaison des binaires hors de la racine web. StyleSmuggler ne change pas la nature de la menace, il en réarme la gravité — l’exploitation sans authentification et l’absence de correctif au moment de la publication la rendent nettement plus dangereuse qu’un incident « routinier » de skimming.

Verdict

Si votre boutique expose GraphQL et que votre vitrine le permet, coupez-le aujourd’hui : c’est la seule parade immédiate documentée, et l’exploitation active est en cours depuis le 4 septembre.

Si votre vitrine headless ou PWA exige GraphQL, déployez des règles de blocage sur les requêtes styles[…], scannez avec eComscan et surveillez les processus [kworker/u:8:0] — puis réappliquez le correctif officiel dès qu’Adobe le publie, espéré le 8 septembre.

Dans tous les cas, ne vous croyez pas protégé par vos patchs à jour : la première victime tournait sous 2.4.6-p15, le niveau de correctif le plus récent de sa branche.

Références

• Sansec — StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack
• The Hacker News — Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores
• Disrex Group — StyleSmuggler mitigation repository
• graycoreio — Magento 2 Style Smuggler patch
• Adobe — Magento / Adobe Commerce security bulletins