Il y a une phrase, dans l’avis publié par Sansec, qui a déclenché chez nous une nuit de vérifications : la première boutique compromise était parfaitement à jour. Correctifs de juillet appliqués, correctifs d’août appliqués, security:patch-status propre. Et compromise quand même.
Ce que dit exactement l’avis Sansec
Le 5 septembre 2026, la société néerlandaise de sécurité e-commerce Sansec a publié un avis intitulé « StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack ». Il a été mis à jour le 7 septembre à 13 h 29 UTC. Sansec indique avoir découvert la campagne le 4 septembre et avoir publié dès le lendemain, précisément parce que des boutiques étaient compromises en temps réel.
La vulnérabilité permet l’exécution de code arbitraire sur le serveur d’une boutique, sans aucune authentification, puis l’installation d’une porte dérobée persistante. Le mécanisme se déroule en deux temps, tel que Sansec le décrit : « (1) Inject (poison) PHP code, for example by generating a failure report. (2) Let Magento execute the poisoned code via a failed payment email. »
Concrètement, l’attaque abuse des propriétés styles du système de gabarits de Magento pour contourner les protections en place, puis déclenche volontairement le courriel Payment Transaction Failed Reminder afin que le code empoisonné soit exécuté au moment du rendu. C’est élégant, et c’est exactement le genre de chaîne qu’aucune règle de pare-feu applicatif générique n’attrape.
Notre avis d’expert
Ce qui distingue cet avis des dizaines d’autres que nous traitons chaque mois, ce n’est ni la note ni la complexité technique : c’est qu’il invalide l’indicateur sur lequel repose la quasi-totalité des politiques de maintenance e-commerce en PME. Nous disons tous à nos clients la même chose depuis dix ans : appliquez les correctifs, tenez votre parc à jour, surveillez le statut. Ici, une boutique ayant fait tout cela correctement a été compromise. Cela ne veut pas dire que la maintenance ne sert à rien, cela veut dire que « à jour » n’est pas un état de sécurité, c’est un état administratif. La différence entre les deux se mesure en jours d’exposition.
Pourquoi « être à jour » ne vous protège pas ici
C’est le point qu’il faut faire remonter à votre direction sans le diluer.
La première victime confirmée tournait sous Magento 2.4.6-p15, avec les correctifs de juillet et août 2026 appliqués et un security:patch-status propre. Sansec précise par ailleurs avoir reproduit la chaîne sur des installations neuves de 2.4.7, 2.4.8 et 2.4.9.
Il n’existe donc, au moment où nous écrivons, aucune version de Magento connue comme non vulnérable. Ce n’est pas un retard de mise à jour : c’est une fenêtre pendant laquelle le correctif n’existe pas. La distinction change complètement la réponse opérationnelle. Face à un retard, on met à jour. Face à une fenêtre sans correctif, on réduit la surface et on surveille.
Au 7 septembre, Sansec indique qu’Adobe n’avait publié ni identifiant CVE, ni avis, ni correctif, ni contournement officiel, le support entreprise ayant confirmé travailler sur un correctif sans date annoncée. Le prochain bulletin de sécurité programmé tombe le 8 septembre — sans garantie qu’il couvre cette faille.
Les 6 vérifications que nous avons menées sur le parc e-commerce
Voici ce que nous avons fait, dans l’ordre, sur les boutiques Magento que nous supervisons.
1. Inventorier ce qui tourne réellement sous Magento. Pas la liste des projets : la liste des domaines qui répondent. Nous avons trouvé deux instances de préproduction accessibles publiquement, oubliées depuis une migration. Une préproduction exposée est une porte d’entrée avec les mêmes identifiants de base de données que la production.
2. Désactiver GraphQL là où il n’est pas nécessaire. C’est l’atténuation recommandée par Sansec. Sur une boutique classique servie en rendu serveur, GraphQL est fréquemment actif sans être utilisé par le front. Le désactiver ne coûte rien. Sur une boutique en tête découplée, il faut mesurer avant : là, l’arbitrage se discute avec le métier, pas en solitaire à 23 heures.
3. Chercher du PHP là où il ne devrait pas y en avoir. La commande recommandée est directe : find pub/media -name '*.php'. Le répertoire des médias ne doit jamais contenir de code exécutable. Un seul résultat justifie une procédure d’incident, pas une suppression discrète du fichier.
4. Vérifier les comptes administrateurs créés depuis le 1er septembre. L’objectif de l’attaquant est la persistance. Un compte administrateur discret est le moyen le plus simple de survivre à un correctif futur.
5. Tester la restauration d’une sauvegarde antérieure au 4 septembre. Pas vérifier qu’elle existe : la restaurer réellement, sur un environnement jetable. Une sauvegarde non testée n’est pas une sauvegarde, et c’est le jour où vous en avez besoin que vous découvrez qu’elle est incomplète.
6. Programmer une relecture du bulletin Adobe du 8 septembre. Avec une consigne écrite : si la faille n’y figure pas, les mesures d’atténuation restent en place et la surveillance reste renforcée. Sans cette consigne, l’attention retombe naturellement au bout de 72 heures.
Vous exploitez une boutique Magento ou Adobe Commerce ?
Nous menons ces six vérifications sur votre parc et vous remettons un état d’exposition écrit sous 48 heures — y compris les préproductions oubliées.
Notre avis d’expert
Le détail qui devrait inquiéter le plus les dirigeants de PME n’est pas technique, il est chronologique. Sansec rapporte, via l’hébergeur Disrex Group, deux boutiques compromises dans une fenêtre de huit heures entre la première attaque observée et la disponibilité de la moindre mesure défensive. Huit heures. Or le délai moyen entre la publication d’un avis et sa prise en compte effective dans une PME française se compte en jours, quand ce n’est pas en semaines : le prestataire doit être joint, un devis doit parfois être validé, une fenêtre de maintenance doit être négociée avec le commerce. Ce n’est pas un problème de compétence, c’est un problème de circuit de décision. Les entreprises qui s’en sortent sont celles qui ont pré-autorisé quelqu’un à agir sans repasser par la chaîne de validation.
Ce que cet épisode devrait changer dans votre maintenance
Trois conclusions, applicables au-delà de Magento.
Séparez « à jour » de « non vulnérable ». Vos indicateurs de supervision mesurent le premier et affichent le second. Tant qu’une faille n’a pas de correctif, un tableau de bord vert est une information sur votre discipline administrative, pas sur votre exposition.
Pré-autorisez une action d’urgence. Nommez une personne, écrivez ce qu’elle a le droit de faire seule — désactiver un composant, couper une préproduction, forcer une rotation d’identifiants — et à partir de quel seuil. Ce document tient sur une page et se rédige à froid.
Traitez les composants tiers comme du code que vous exploitez. C’est la même logique que celle appliquée à toute dépendance externe, et elle vaut bien au-delà du e-commerce : les mêmes défauts de désérialisation et de contrôle d’accès se retrouvent dans les audits de code que mènent les équipes spécialisées en audit de smart contracts, sur un terrain technique différent mais avec un mode de défaillance identique.
Si votre parc n’a jamais fait l’objet d’un inventaire d’exposition formel, c’est le moment : nous détaillons la méthode dans notre guide sur la protection de la chaîne d’approvisionnement logicielle, et la suite logique après un incident dans le plan de remédiation en 7 étapes.
Notre avis d’expert
Une remarque sur le calendrier, parce qu’elle se reproduit à chaque fois. Les campagnes d’exploitation démarrent souvent en fin de semaine et les avis tombent le week-end : ici, découverte le vendredi 4 septembre, publication le samedi 5. Ce n’est pas un hasard, c’est un choix rationnel de l’attaquant, qui sait que les équipes sont réduites et que les circuits de validation sont à l’arrêt. La conséquence pratique est simple à énoncer et difficile à mettre en oeuvre : si votre dispositif de réaction suppose qu’un décideur est joignable en semaine, il est calibré pour le mauvais moment de la semaine.
À faire cette semaine
Aujourd’hui : lister les instances Magento qui répondent réellement, préproductions comprises, et lancer find pub/media -name '*.php' sur chacune.
Aujourd’hui également : désactiver GraphQL partout où il n’est pas consommé, et vérifier les comptes administrateurs créés depuis le 1er septembre.
Cette semaine : restaurer pour de vrai une sauvegarde antérieure au 4 septembre sur un environnement jetable, et écrire la page d’autorisation d’urgence.
Le 8 septembre : lire le bulletin Adobe. S’il ne couvre pas StyleSmuggler, maintenir les atténuations et la surveillance renforcée jusqu’au correctif.
Questions fréquentes
Qu’est-ce que la faille StyleSmuggler exactement ?
StyleSmuggler est une vulnérabilité d’exécution de code à distance, exploitable sans authentification, qui touche Magento Open Source et Adobe Commerce. Elle a été publiée le 5 septembre 2026 par la société néerlandaise Sansec sous le titre « StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack », après la découverte d’une campagne d’exploitation le 4 septembre. L’attaque se déroule en deux temps : l’attaquant empoisonne d’abord du code PHP, par exemple en provoquant la génération d’un rapport d’erreur, puis il fait exécuter ce code par Magento via un courriel de paiement échoué. Le mécanisme abuse des propriétés styles du système de gabarits pour contourner les protections existantes.
Mon site est à jour, suis-je protégé ?
Non, et c’est précisément ce qui rend cet avis inhabituel. La première victime confirmée par Sansec tournait sous Magento 2.4.6-p15 avec les correctifs de juillet et d’août 2026 appliqués, et un security:patch-status propre. Sansec indique par ailleurs avoir reproduit la chaîne d’exploitation sur des installations neuves de 2.4.7, 2.4.8 et 2.4.9. Autrement dit, l’état à jour de votre installation ne constitue pas une protection contre cette faille, parce qu’aucun correctif la couvrant n’a encore été publié. Les tableaux de bord de supervision qui affichent un parc conforme donnent ici une fausse assurance.
Que faire tant qu’Adobe n’a pas publié de correctif ?
Sansec recommande de désactiver temporairement GraphQL en attendant un correctif officiel, ce qui constitue la mesure d’atténuation principale à ce stade. En complément, recherchez la présence de fichiers PHP dans les répertoires de médias, avec une commande du type find pub/media -name '*.php', car ce répertoire ne devrait jamais contenir de code exécutable. Effectuez également une rotation des identifiants Magento si des processus d’arrière-plan suspects sont constatés, et vérifiez que vos sauvegardes se restaurent réellement avant d’en avoir besoin. Ces mesures ne remplacent pas un correctif : elles réduisent la surface pendant la fenêtre d’exposition.
Comment savoir si une boutique a déjà été compromise ?
L’objectif de l’attaquant étant d’installer une porte dérobée persistante, les traces se trouvent surtout sur le disque et dans les comptes. Recherchez les fichiers PHP créés ou modifiés récemment sous pub/media et plus largement dans les répertoires accessibles en écriture, les comptes administrateurs créés depuis début septembre, les tâches planifiées inconnues, et les processus d’arrière-plan inhabituels. L’hébergeur Disrex Group, cité par Sansec, a confirmé des cas d’exploitation indépendants sur au moins deux boutiques, dont deux compromises dans une fenêtre de huit heures entre la première attaque observée et la disponibilité d’une mesure défensive. En cas de doute sérieux, une restauration antérieure au 4 septembre est plus sûre qu’un nettoyage manuel.