stylesmuggler-ioc-toolkit

StyleSmuggler (CVE-2026-75650) boîte à outils IOC pour Magento Open Source et Adobe Commerce. Détectez les boutiques compromises, les implants Rust, les shells web PHP, les artefacts de persistance et les indicateurs de compromission connus.

Couverture du correctif officiel d'Adobe — vérifiez ceci avant de supposer que vous êtes en sécurité

Si vous utilisez une version plus ancienne et non prise en charge, Adobe ne vous livre pas de correctif même si vous êtes tout aussi exploitable. Voir docs/PATCHING.md pour vos options.

Ces informations évoluent rapidement. Recoupez avec les sources primaires avant d'agir : l'avis de Sansec et le bulletin d'Adobe. Voir docs/TIMELINE.md pour un journal continu et citez vos sources lorsque vous mettez à jour quoi que ce soit ici.

Ce qu'est réellement StyleSmuggler

Le paramètre GraphQL styles de Magento et son analyse de fichiers basée sur l'injection de dépendances sont abusés comme une primitive d'exécution différée basée sur des fichiers en deux étapes plutôt qu'un point d'injection unique et évident :

1. Empoisonnement. Des données contrôlées par l'attaquant atteignent un fichier journal ou de rapport généré par Magento (var/log/system.log via un code de magasin invalide que Magento journalise textuellement, ou var/report/<hash>), introduites via le paramètre GraphQL styles[], un en-tête de requête muté, ou (pour le second attaquant sans lien ci-dessous) l'en-tête Store:.
2. Détonation. L'attaquant déclenche l'e-mail standard « Payment Transaction Failed Reminder » de Magento. Le rendu de cet e-mail (chemin getProcessedTemplate de Magento) parcourt un chemin de code qui permet au scanneur de code DI de Magento d'include() le fichier empoisonné, exécutant le PHP de l'attaquant. Vous n'avez pas besoin d'ouvrir l'e-mail — son rendu côté serveur suffit — et la chaîne peut se déclencher même lorsque la livraison du courrier échoue.

Un signe d'alerte précoce facile, sans outillage : un e-mail « Payment Transaction Failed Reminder » déformé dans votre boîte de réception avec des balises {{var ...}} brutes non rendues et une adresse client se terminant par .invalid. C'est souvent le premier signe visible, avant que quiconque ne consulte un journal.

Les mises à jour de Sansec ont confirmé un second chemin d'exploitation indépendant pour la même campagne d'implant Rust : même les magasins qui avaient déplacé le stockage de sessions de Redis vers la base de données ont été compromis — la seconde tentative du même opérateur a réussi quelques secondes plus tard en utilisant un fichier téléversé via la fonctionnalité options personnalisées client de Magento. Déplacer le stockage de sessions n'est pas un correctif en soi.

Séparément, le 7 septembre, Sansec a trouvé un attaquant totalement sans lien utilisant le même point d'entrée StyleSmuggler pour une charge utile bien plus simple : un web shell PHP déposé dans le cache d'images produit de Magento (pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php), précédé d'une sonde de reconnaissance qui cache sa charge utile dans l'en-tête HTTP Store: et exfiltre ses découvertes via DNS plutôt qu'une réponse HTTP. C'est un « outillage standard », selon Sansec — pas une campagne soutenue — mais cela signifie qu'un seul hôte vulnérable peut porter deux intrusions sans lien via une seule faille. Nettoyer l'implant Rust ne signifie pas que votre magasin est propre.

L'implant Rust lui-même a également évolué : la construction originale se faisant passer pour [kworker/u:8:0] (4 sept.) a été suivie d'une construction se faisant passer pour fc-cache v2.1.4 (6 sept.) qui émet des balises déguisées en trafic NTP, puis d'un redéploiement se faisant passer pour chronyd v2.1.5 (7 sept.) du même implant, même ID d'agent — preuve que l'attaquant itère activement pour échapper à toute détection que vous publiez. Sansec indique n'avoir pas encore vu de preuve que cet implant ait été armé au-delà de la persistance/reconnaissance — ne lisez pas cela comme une réassurance compte tenu du web shell fonctionnel de l'attaquant sans lien sur le même chemin d'accès.

Voir docs/FAQ.md pour des réponses rapides, docs/VULNERABILITY.md pour l'analyse technique complète et les sources, docs/PATCHING.md pour appliquer le correctif officiel d'Adobe, et docs/INCIDENT_RESPONSE.md pour savoir quoi faire si le scanner trouve quelque chose.

Démarrage rapide

1. Corrigez, si votre version est couverte :

2. Scannez pour une compromission existante quel que soit l'état du correctif — corriger arrête la nouvelle exploitation, cela ne nettoie pas une backdoor ou un web shell existant :

Ou la version Python pour une sortie structurée (JSON), par exemple pour alimenter un SIEM :

Les deux scripts sont en lecture seule par défaut — ils détectent et rapportent, ils ne tuent pas les processus ni ne suppriment les fichiers sauf si vous passez --remediate, car un nettoyage prématuré détruit les preuves forensiques (voir docs/INCIDENT_RESPONSE.md).

Ce que vérifie le scanner

• Artefacts connus de persistance sur le système de fichiers pour les trois constructions observées de l'implant Rust :
  • Construction [kworker/u:8:0] : ~/.local/share/.gvfsd/gvfsd-user, ses fichiers de verrou, /tmp/.kw_*, /tmp/.gvfsd_*
  • Construction fc-cache v2.1.4 (6 sept.) : ~/.cache/fontconfig/fc-cache, /tmp/.fc_<8hex>.lock
  • Construction chronyd v2.1.5 (7 sept.) : /tmp/.chrony-<8hex>/chronyd
• Les entrées crontab auto-restauratrices que l'implant écrit directement dans le spool cron — toutes les 5 minutes pour la construction gvfsd-user, deux fois par heure (13,43 * * * *) pour fc-cache
• Un processus se faisant passer pour [kworker/u:8:0], fc-cache ou chronyd qui n'est pas détenu par root (ou, pour fc-cache/chronyd, ne correspond pas au vrai binaire système)
• SHA-256 des binaires sur disque et de l'image /proc/<pid>/exe en direct (les deux peuvent différer — l'implant a été observé se mettant à jour en mémoire)
• Fichiers journal/rapport empoisonnés (var/log/system.log, var/report/) pour du PHP injecté, les deux formes connues d'en-tête déclencheur (X-TRACE-<10hex> et X-<12hex>), et les marqueurs de campagne du second attaquant sans lien (ss5_/ss6_<hex>) et le domaine canari DNS (oast.site)
• Marqueurs de réponse prouvant l'exécution (MG<20hex>::...::/MG<20hex>) laissés dans les journaux lorsque la charge utile a réellement été exécutée
• Fichiers PHP sous pub/media — qui ne devraient jamais contenir de PHP exécutable sur un magasin Magento correctement configuré — correspondant au modèle de dépôt de web shell du second attaquant
• Connexions établies vers les hôtes C2/téléchargement publiés — y compris l'émission de balises façonnée NTP de la construction fc-cache/chronyd vers ntp.timesync.to:123/UDP (et solutions de repli), et ses appels HTTP simples vers des services publics de recherche d'IP
• Comptes de connexions Redis locales anormaux (la collecte de sessions a été observée entièrement sur 127.0.0.1:6379, avec zéro trafic C2 sortant — un réseau silencieux n'est pas un réseau propre) — et notez que déplacer les sessions hors de Redis seul ne ferme pas le second vecteur d'exploitation basé sur le téléversement de fichiers

Liste complète des indicateurs avec sources : iocs/.

Correction et atténuation

1. Appliquez le hotfix officiel d'Adobe (VULN-39341 / APSB26-146) si votre version est couverte — voir docs/PATCHING.md pour les identifiants, où l'obtenir et comment l'appliquer. C'est désormais la priorité, avant les atténuations provisoires ci-dessous.
2. Si vous ne pouvez pas corriger immédiatement, ou si votre version n'est pas couverte, utilisez les atténuations provisoires dans mitigations/ :
   • Bloquez ou limitez le débit du chemin de livraison styles[] de GraphQL (nginx / Apache)
   • Bloquez l'exécution PHP sous pub/media/pub/static (nginx / Apache) — défense ciblée contre la technique de web shell du second attaquant sans lien
   • Règles ModSecurity pour l'inspection du corps POST et fail2ban comme filet de sécurité réactif
   • Voir mitigations/README.md pour les limites de portée — aucune de ces mesures ne ferme le vecteur des options personnalisées client ni la livraison par en-tête Store: du second attaquant.
3. Exécutez le scanner de compromission quel que soit l'état du correctif/atténuation. Corriger et atténuer arrêtent la nouvelle exploitation ; ni l'un ni l'autre ne nettoie une backdoor ou un web shell déjà déposé.
4. Si le scanner trouve quelque chose, traitez l'hôte comme entièrement compromis, pas simplement « backdoor présente ». L'exécution de code en tant qu'utilisateur du site expose tout ce que cet utilisateur peut lire, à commencer par app/etc/env.php. Au minimum, après confinement : videz le stockage de sessions (Redis et/ou BDD), faites pivoter la crypt/key de Magento, tous les mots de passe administrateur (et invalidez les sessions administrateur existantes), le mot de passe de la base de données, chaque clé API de fournisseur de paiement et autre identifiant d'intégration dans env.php, ainsi que toute clé SSH/déploiement que l'utilisateur du site pouvait lire. Vérifiez également la table admin_user pour un compte frauduleux et pub/media/ / pub/static/ / les répertoires de thèmes pour des web shells déposés — à la fois ceux de l'implant Rust et ceux du second attaquant sans lien — avant de considérer un magasin comme propre. Étapes complètes ordonnées : docs/INCIDENT_RESPONSE.md.

Structure du dépôt

Termes fréquemment recherchés

CVE-2026-75650, APSB26-146, VULN-39341, zero-day Magento 2026, zero-day Adobe Commerce, correctif StyleSmuggler, vulnérabilité GraphQL Magento, RCE paramètre styles Magento, malware gvfsd-user, backdoor Magento fc-cache, malware Magento chronyd, malware processus kworker Magento, détournement de session Redis Magento, RCE non authentifiée Magento septembre 2026, exploit Magento 2.4.9, suppression backdoor Adobe Commerce, web shell Magento pub/media, eComscan StyleSmuggler, Sansec Shield StyleSmuggler.

Sources et provenance

Chaque indicateur de ce dépôt remonte à une source publiée et citée — principalement l'avis de Sansec (mis à jour au moins jusqu'au 2026-09-07 20:50 UTC), le bulletin APSB26-146 d'Adobe, et des analyses de réponse à incident communautaires de répondants ayant géré des infections en direct. Voir la citation en bas de chaque fichier dans iocs/.

Ne traitez rien ici comme exhaustif ou définitif. Les IOC (en-têtes déclencheurs, chaînes d'agent utilisateur, déguisements d'implant, et désormais les marqueurs de campagne d'un second attaquant) ont déjà changé plusieurs fois en quelques jours après la divulgation ; attendez-vous à ce qu'ils changent encore. Faites correspondre les formes et les comportements, pas seulement les chaînes littérales, partout où les scripts le permettent.

Contribution

Vous avez vu une variante, un nouveau hachage, une nouvelle adresse source ou un faux positif ? Ouvrez une issue ou une PR avec ce que vous avez observé et comment vous l'avez observé. Merci de :

• Rédiger les détails identifiants de votre propre organisation avant de partager.
• Ne pas publier de charges utiles d'exploitation ou de requêtes déclencheurs fonctionnelles ici — indicateurs et logique de détection uniquement.
• Signaler la vulnérabilité sous-jacente elle-même à Sansec et à l'Adobe PSIRT, pas à ce dépôt.

Licence

MIT pour le code de ce dépôt (voir LICENSE). Les données d'indicateurs sont fournies « en l'état » pour un usage défensif, avec les sources notées tout au long.

Avertissement

Ceci est un outillage défensif non officiel construit par la communauté, pas un produit Adobe ou Sansec, et n'est affilié à aucun des deux. Il est fourni sans garantie. Le correctif officiel d'Adobe (APSB26-146) a été publié, mais la couverture est limitée à des versions de produits spécifiques — vérifiez le bulletin de sécurité d'Adobe directement avant de supposer que votre installation est couverte ou corrigée.