Le zero-day « StyleSmuggler » d'Adobe Commerce a frappé des boutiques trois jours avant le correctif

Le 4 septembre 2026, à 22 h 20 UTC, des attaquants ont commencé à frapper des boutiques Magento et Adobe Commerce avec un exploit d'exécution de code à distance non authentifié pour lequel aucun correctif de l'éditeur n'existait encore. La faille, enregistrée sous CVE-2026-75650 et baptisée « StyleSmuggler » par la société néerlandaise de sécurité Sansec, porte un score CVSS de 10.0, le maximum. Adobe a publié le bulletin d'urgence APSB26-146 et le hotfix VULN-39341 le 7 septembre, trois jours après la première intrusion confirmée. Au moment où un correctif a existé, les attaquants avaient déjà eu le temps d'installer des portes dérobées persistantes sur les boutiques compromises, et le correctif ne les supprime pas.

À lire aussi: La CISA classe PolyShell comme exploitée pendant que la campagne Magento touche des centaines de boutiques · Le Patch Tuesday d'octobre 2026 de Microsoft établit un record avec 1 407 correctifs.

Cet écart, c'est l'histoire. Sur une plateforme de commerce électronique moderne, une faille d'exécution de code non authentifiée est à peu près ce qui se fait de pire : la surface d'attaque se résume à « la boutique est-elle joignable depuis Internet », et le butin comprend les données clients, les données de paiement, les identifiants d'administration et la possibilité d'injecter des skimmers de paiement dans le tunnel d'achat. StyleSmuggler s'est révélé exploitable sans configuration exotique. Sansec a reproduit la chaîne complète sur des installations propres de Magento Open Source 2.4.7, 2.4.8 et 2.4.9, et une victime confirmée exécutait 2.4.6-p15 avec les correctifs de juillet et août appliqués et un rapport security:patch-status propre, la preuve que la vérification habituelle « sommes-nous à jour ? » ne suffisait pas.

La chaîne en deux étapes

StyleSmuggler abuse du système de gabarits de Magento d'une manière qui scinde l'attaque en une étape silencieuse et une étape de déclenchement. D'abord, un attaquant non authentifié envoie une requête GraphQL dont la propriété styles transporte une charge utile PHP injectée. La charge ne s'exécute pas immédiatement; elle est écrite sur disque dans un fichier que Magento génère dans le cadre de son fonctionnement normal, par exemple un rapport d'échec de paiement. Parce que la charge arrive déguisée en données de style, elle se glisse au-delà des protections censées empêcher le code exécutable d'entrer dans les gabarits, d'où le nom.

La deuxième étape est la partie astucieuse. Magento restitue ensuite ce contenu empoisonné en construisant l'un de ses propres courriels transactionnels standard, le « Payment Transaction Failed Reminder ». Le PHP malveillant s'exécute côté serveur pendant le rendu du gabarit. Personne n'a besoin d'ouvrir le courriel, et l'attaque fonctionne même si le message n'est jamais remis : un marchand qui ne voit jamais de message suspect n'est donc pas tiré d'affaire. Sansec note qu'une soudaine rafale de ces rappels de paiement échoué mérite tout de même une enquête, même si des refus de paiement ordinaires produisent la même notification.

La chaîne compte parce qu'elle ne dépend ni d'un thème mal configuré ni d'un administrateur négligent. Sansec a rapporté que le choix du stockage des sessions ne change rien et qu'un opérateur a échoué une fois contre une boutique utilisant des sessions adossées à Redis, puis a réussi huit secondes plus tard en acheminant la charge par un fichier téléversé via les options personnalisées de Magento. Une boutique standard sur une branche actuelle était concernée.

Un correctif sans numéro de version

La remédiation d'Adobe est inhabituelle, et cela a des conséquences pour quiconque veut prouver qu'il est protégé. L'entreprise n'a pas livré de nouvelle version de Magento ou de Commerce. À la place, le champ de solution d'APSB26-146 renvoie à la chaîne « Hotfix for CVE-2026-75650 », livrée sous forme de fichier de correctif Composer, VULN-39341-composer-patches.zip, appliqué via le processus de correctifs Composer d'Adobe. Comme l'a souligné la publication de sécurité Severity Daily, un correctif Composer ne modifie pas la chaîne de version du produit : une boutique qui a appliqué le hotfix et une qui ne l'a pas fait déclarent la même version d'Adobe Commerce. Un scanner de vulnérabilités classique fonctionnant par correspondance de versions ne peut pas les distinguer. La vérification recommandée par Adobe est une commande shell sur l'hôte (dans le cloud, vendor/bin/magento-patches -n status filtrée sur 39341), qui fonctionne serveur par serveur mais ne s'étend pas à un contrôle de conformité à l'échelle d'un parc.

La plage concernée est large. Adobe liste Adobe Commerce 2.4.4 à 2.4.9, y compris les versions d'août 2026 et les versions antérieures de chaque branche; Adobe Commerce B2B 1.3.3 à 1.5.3; et Magento Open Source 2.4.6 à 2.4.9. Adobe précise que le hotfix n'a été testé que contre les versions d'août 2026 de ces branches et que la compatibilité avec les versions antérieures n'est pas confirmée. Sansec a rapporté séparément une reproduction sur des installations propres de 2.4.7, 2.4.8 et 2.4.9.

Adobe a aussi clairement indiqué que le correctif ne constitue pas tout le travail. Comme la faille permet à un attaquant d'exécuter du code en tant que serveur web, tout ce que la boutique pouvait atteindre est potentiellement exposé, y compris la clé de chiffrement qui protège les secrets stockés. L'avis de la base de connaissances demande aux marchands de faire tourner la clé de chiffrement puis chaque identifiant que cette clé protégeait : mots de passe d'administration, jetons d'intégration REST, SOAP et GraphQL, secrets de clients OAuth, identifiants d'API des passerelles de paiement, identifiants de base de données, clés SSH et de déploiement, et clés d'API d'extensions tierces. Faire tourner la clé seule, avertit la page, n'invalide pas les identifiants qu'un attaquant a déjà lus; il faut les faire tourner à la source, par exemple auprès de la passerelle de paiement.

Avant l'arrivée du hotfix, l'atténuation provisoire consistait à désactiver GraphQL. C'est un compromis inconfortable pour les boutiques modernes, pilotées par API et sans interface, qui dépendent de GraphQL pour leur front-end. C'était néanmoins le moyen le plus direct de couper l'étape d'injection tant qu'aucun correctif n'existait.

Une porte dérobée déguisée en système d'exploitation

Ce qui fait de StyleSmuggler autre chose qu'une histoire de correctif, c'est ce que les attaquants laissent derrière eux. L'analyse médico-légale de Sansec décrit un petit programme en Rust qui s'exécute en arrière-plan et se connecte à un serveur de commande et contrôle. Les premiers échantillons contactaient 99.84.67.186; les versions ultérieures déguisent leur trafic en Network Time Protocol, en envoyant des paquets UDP de 48 octets vers le port 123 (un port et un protocole que la plupart des filtres de sortie laissent passer), seuls les quatre premiers octets ressemblant réellement à du NTP. Le reste transporte un enregistrement MessagePack contenant l'ID de l'agent, le nom d'hôte, le nom d'utilisateur, la version du système d'exploitation, l'utilisation de la mémoire et du disque, la disponibilité, le fait qu'il s'exécute en root et la version de l'implant. Sansec a indiqué que, lors de sa mise à jour du 11 septembre, l'implant résolvait ntp.timesync.to et ntp.timesysnc.net vers 185.157.160.251, l'adresse à bloquer si le filtrage par nom n'est pas possible.

L'implant se cache à la vue en adoptant les noms des tâches d'entretien ordinaires de Linux. La première variante apparaissait comme [kworker/u:8:0], imitant un fil de travail du noyau. Les versions suivantes se sont renommées en fc-cache, se copiant vers ~/.cache/fontconfig/fc-cache, puis en chronyd, le vrai nom du démon NTP sur la plupart des distributions. La persistance provient d'entrées cron écrites directement dans le spoule cron plutôt qu'ajoutées via crontab -e, de sorte que les journaux système ne contiennent aucune ligne REPLACE; les planifications observées s'exécutaient toutes les 30 minutes. Sansec a aussi relevé une variante capable de se relancer avec un PID parent de 1 sans aucune entrée cron, ce qui signifie qu'un crontab vide n'est pas la preuve d'un hôte propre.

Un second opérateur, sans lien, a été observé sur les mêmes boutiques victimes. Le 7 septembre, Sansec a analysé un dropper PHP de 485 octets qui écrit un shell web dans le cache d'images produits de Magento sous pub/media. Le shell renvoie un 404 à toute requête dépourvue de l'en-tête secret X-Cache-Token, et lorsque l'en-tête est présent, il exécute du PHP arbitraire depuis le paramètre POST task. Sansec a récupéré le dropper dans un en-tête de requête Store:, encore échappé en JSON depuis l'enregistrement dans lequel Magento l'avait consigné, ce qui confirme qu'il est entré via StyleSmuggler. Les deux campagnes partagent des victimes mais pas leurs outils. La FAQ de Tenable sur la faille a signalé plusieurs boutiques victimes dans différentes campagnes et le fait que la société de réponse aux incidents Disrex avait une expérience directe d'au moins deux boutiques compromises; au 8 septembre, aucune attribution publique à un groupe de menaces nommé n'existait.

Le correctif ferme la brèche, mais ne nettoie pas une boutique déjà touchée. Les boutiques étaient exploitées depuis trois jours avant que le hotfix n'existe.

Pourquoi ce cas frappe plus fort

Adobe Commerce et Magento font tourner une grande partie des boutiques en ligne du monde, et beaucoup d'entre elles sont des petites ou moyennes entreprises sans équipe de sécurité dédiée. Cette combinaison amplifie chaque caractéristique de l'incident. L'exploit ne nécessitait aucune connexion, l'exposition était donc large. La fenêtre avant correctif s'est étalée sur un week-end dans certaines régions. Et les charges utiles étaient conçues pour survivre à la remédiation. Un marchand qui corrige dès le premier jour peut encore héberger un attaquant arrivé au jour zéro.

Il y a aussi une dimension de conformité. La CISA a ajouté CVE-2026-75650 à son catalogue des vulnérabilités exploitées connues le 8 septembre et a fixé une échéance fédérale de remédiation au 11 septembre, une fenêtre de trois jours bien plus serrée que les semaines habituellement accordées. Cette inscription oblige les agences fédérales à appliquer des atténuations selon les nouvelles règles de correctifs fondées sur le risque et à réaliser un triage médico-légal, le genre d'obligation qui devient difficile lorsque la remédiation est un correctif sans numéro de version et une liste de rotation des identifiants. La conclusion pratique pour les opérateurs du secteur privé est la même : l'échéance ne les lie peut-être pas, mais l'urgence, oui.

L'épisode renforce aussi un schéma dans la sécurité du commerce électronique. Les couches de gabarits et de rendu restent la voie d'entrée, parce qu'elles se situent entre le contenu fourni par l'utilisateur et l'exécution côté serveur, et parce que la chaîne de courriel est facile à négliger. La recommandation de Sansec de rechercher les fichiers .php fraîchement écrits sous pub/media est révélatrice (ce répertoire est censé servir des images et du cache, jamais du code), et la surveillance de l'intégrité des fichiers est bien adaptée pour repérer exactement ce type d'anomalie.

Ce qu'il faut surveiller

Quatre choses détermineront la manière dont cet incident restera dans les mémoires.

Premièrement, si Adobe transforme le hotfix en version numérotée. Les correctifs Composer sont une réponse d'urgence raisonnable, mais l'absence de numéro de version aveugle tout inventaire d'actifs et tout scanner, et rend invisible aux outils sur lesquels s'appuient la plupart des organisations la différence entre corrigé et non corrigé.

Deuxièmement, si l'implant est militarisé. Au moment où Sansec a publié son analyse, rien n'indiquait que la porte dérobée avait servi à autre chose qu'à émettre des signaux, et le logiciel malveillant n'était reconnu par aucun fournisseur de sécurité hormis Sansec. Cela pourrait changer rapidement.

Troisièmement, si le shell web du second opérateur est la tête de pont d'une campagne plus large de type Magecart. Une RCE non authentifiée qui atteint le tunnel d'achat est un point d'appui naturel pour du code de vol de cartes, et la fenêtre entre la première exploitation et la divulgation a laissé aux attaquants le temps de se positionner.

Quatrièmement, combien de boutiques ont réellement été compromises. Les chiffres de victimes confirmées restent faibles et anecdotiques. Le nombre réel ne surgira peut-être que lorsque les marchands mèneront des évaluations de compromission et trouveront des processus nommés kworker, fc-cache ou chronyd qui n'ont rien à y faire. D'ici là, la posture honnête pour quiconque a exploité une boutique Magento exposée à Internet entre le 4 septembre et le moment du correctif est de présumer la compromission jusqu'à preuve du contraire, et de faire tourner les identifiants seulement après le correctif et la recherche, dans cet ordre.