StyleSmuggler (CVE-2026-75650) : RCE non authentifiée critique sur Magento et Adobe Commerce
La vulnérabilité "StyleSmuggler" (CVE-2026-75650, CVSS 10.0) permet une exécution de code à distance sans authentification. Il faut noter que les attaques ont commencé trois jours avant la publication du hotfix par Adobe. La première victime confirmée faisait pourtant tourner une version totalement à jour des correctifs de sécurité de juillet et août 2026.
Synthèse rapide
CVE : CVE-2026-75650 — nom de code "StyleSmuggler"
CVSS : 10.0 (priorité 1, la plus haute chez Adobe)
Type : RCE (exécution de code) non authentifiée via le moteur de templates de Magento
Découvreur : Sansec (Forensics Team), alerte publiée le 5 septembre 2026
Versions affectées : Adobe Commerce et Magento Open Source 2.4.4 à 2.4.9, Adobe Commerce B2B 1.3.3 à 1.5.3 (versions antérieures probablement concernées mais non testées par Adobe)
Statut : exploitation active depuis le 4 septembre 2026 a minima, correctif Adobe publié le 7 septembre (APSB26-146, hotfix VULN-39341)
Impact observé : dépôt d'un backdoor persistant, exfiltration potentielle des identifiants et clé de chiffrement Magento
Chronologie
Date | Évènement |
4 septembre 2026 | Début des attaques observées par Sansec, avant toute divulgation publique |
5 septembre 2026 | Sansec publie une alerte anticipée : boutiques compromises en temps réel, aucun CVE ni correctif disponible |
6 septembre 2026 | Sansec documente un second acteur menant des sondes de reconnaissance ; variante du malware déguisée en fc-cache |
7 septembre 2026, 20h20 UTC | Adobe publie APSB26-146, priorité 1, attribue CVE-2026-75650 (CVSS 10.0) |
7 septembre 2026 | Nouvelle variante du malware déguisée en chronyd observée |
8 septembre 2026 | Situation toujours en cours d'investigation ; Sansec continue de mettre à jour les indicateurs |
Analyse technique
StyleSmuggler exploite le moteur de rendu de templates de Magento (layout XML / système de blocs) en détournant les propriétés de style pour franchir une frontière de confiance qui, normalement, empêche l'exécution de contenu fourni par l'utilisateur. L'attaque se déroule en deux temps distincts, sans jamais nécessiter d'authentification :
Étape 1 — Injection (empoisonnement). L'attaquant fait parvenir un payload PHP à Magento via une voie normalement inoffensive — les indicateurs publiés mentionnent des requêtes vers /graphql avec des paramètres styles[...], ainsi que des routes comme /paypal/transparent/response/ et /customer/section/load/. Le contenu malveillant se retrouve écrit dans les fichiers de rapport ou de journalisation internes de Magento (var/report/, var/log/ selon les variantes), généralement en provoquant volontairement une erreur applicative.
Étape 2 — Déclenchement. Le payload injecté reste dormant jusqu'à ce que Magento génère en interne l'e-mail standard de rappel d'échec de paiement ("Payment Transaction Failed Reminder"). Le rendu de ce template déclenche l'exécution du code empoisonné — sans qu'aucun destinataire n'ait besoin d'ouvrir, ni même de recevoir, cet e-mail. Une fois l'exécution obtenue, un dropper PHP teste plusieurs fonctions capables de lancer un process jusqu'à en trouver une non désactivée, puis télécharge et lance un implant persistant.
Point notable pour la priorisation : 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 la première victime confirmée exécutait une version 2.4.6-p15 avec tous les correctifs de sécurité de juillet et août 2026 appliqués, statut de patch "clean".
Le rattachement à une classe de vulnérabilité "template/style injection" plutôt qu'à un point d'entrée isolé signifie qu'aucune version de la ligne 2.4.x n'était à l'abri avant le hotfix.
Payload et persistance observées
Sansec documente au moins trois variantes du binaire déposé, cherchant à se fondre dans les processus système légitimes :
un processus caché sous le nom [kworker/u:8:0] (variante initiale)
une variante fc-cache, imitant le générateur de cache de polices (apparue le 6 septembre)
une variante chronyd, imitant le démon NTP (apparue le 7 septembre)
Un shell web additionnel a également été identifié, répondant par un 404 normal sauf en présence d'un en-tête X-Cache-Token spécifique, ce qui le rend invisible aux vérifications superficielles. La persistance est assurée par une entrée cron s'exécutant toutes les cinq minutes et qui se réinstalle automatiquement si elle est supprimée.
Un cas a montré la même ligne cron réécrite plus de 1700 fois. Un détail opérationnel important : l'implant s'installe hors de la racine documentaire Magento (répertoire personnel de l'utilisateur système), ce qui signifie qu'un scan limité au dossier du projet peut déclarer la boutique saine à tort.
Indicateurs de détection
Processus et persistance (sur le serveur applicatif) :
crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.gvfsd-* 2>/dev/null
ps -eo pid,user,comm,args | grep -iE 'kworker|fc-cache|chronyd' | grep -v ' root '
grep -rl 'X_TRACE_' var/report/ var/log/ 2>/dev/null
grep -r 'crontab command not allowed' /var/log/
Fichiers de persistance rapportés : ~/.local/share/.gvfsd/gvfsd-user, ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock, /tmp/.kw_<random><random>. L'entrée cron associée s'exécute toutes les cinq minutes.
Journaux applicatifs : rechercher dans les logs d'accès des motifs styles[, generatorClass, with_resolved ou cdnflare sur les routes /graphql, /paypal/transparent/response/ et /customer/section/load/. Ces routes sont légitimes en elles-mêmes — c'est la corrélation avec les payloads et les artefacts sur disque qui fait la preuve.
Indicateurs réseau (infrastructure attaquant, à corréler avec vos flux sortants) :
Distribution du malware : 247[.]cdnflare[.]xyz, 209.141.43.95
C2 (WebSocket sur TLS) : 99.84.67.186:443
Shell distant : windwsecurity[.]run:443
Trafic C2 déguisé en NTP (UDP/123) : ntp.timesysnc[.]net, time.microsft[.]run, pool.microsft[.]studio
Sources d'attaque rapportées : 88.216.72.181, 5.181.86.133, 91.238.181.19
Ces domaines typosquattent volontairement des noms crédibles (services Microsoft, NTP) pour se fondre dans le trafic sortant normal — la chasse aux menaces ne doit donc pas se limiter au trafic HTTPS.
Mitigation
Appliquer le hotfix Adobe. Télécharger VULN-39341-composer-patches.zip depuis repo.magento.com et l'installer comme patch composer. Vérifier l'installation avec vendor/bin/magento-patches -n status | grep "39341\|Status". Le correctif est distribué en hotfix, pas en version complète.
Ne pas se fier au seul statut "patché". Le patch ferme la porte d'entrée mais ne nettoie pas une instance déjà compromise. Les attaques ont commencé trois jours avant l'existence du correctif : scanner systématiquement avant de considérer une boutique comme saine.
Mesure de contournement en attendant le déploiement du patch : désactiver GraphQL si aucune fonctionnalité critique n'en dépend, ou déployer une règle WAF bloquant les paramètres styles[ sur les endpoints exposés.
Rotation complète des secrets après application du correctif, en commençant par la clé de chiffrement Magento, puis l'ensemble des identifiants qu'elle protège (cf. section impact).
Recherche de compromission sur tous les nœuds, pas seulement ceux présentant des symptômes visibles — l'implant peut être dormant.
Reconstruction des nœuds confirmés compromis plutôt que nettoyage in situ, compte tenu du mécanisme de persistance auto-réparant observé.
Recommandations segmentées
Éditeurs et intégrateurs Magento/Adobe Commerce
Traiter ce correctif en urgence absolue, hors cycle de mise à jour habituel, quel que soit le patch level actuel du client.
Vérifier la compatibilité du hotfix avec les extensions tierces avant déploiement en production, tout en gardant à l'esprit que le délai d'exposition prime sur le confort de test habituel.
Informer proactivement les clients hébergeant du e-commerce Magento, même ceux estimant être à jour.
SOC / Blue Team
Intégrer les indicateurs réseau et fichier ci-dessus dans les règles de détection (EDR, SIEM, sondes réseau), y compris la surveillance du trafic UDP/123 sortant.
Étendre la chasse aux processus non-root portant des noms de processus système légitimes (kworker, fc-cache, chronyd) mais exécutés depuis des chemins anormaux (répertoires temporaires ou cache utilisateur).
Ne pas limiter les scans de compromission au périmètre applicatif Magento : l'implant s'installe hors de la racine documentaire.
Réponse à incident
Considérer toute instance Magento/Adobe Commerce exposée entre le 4 et le 7 septembre 2026 comme potentiellement compromise jusqu'à preuve du contraire, indépendamment du patch level.
En cas de détection positive, reconstruire les nœuds concernés plutôt que de simplement supprimer les artefacts identifiés, la persistance observée se réinstallant automatiquement.
Documenter les marqueurs de compromission trouvés dans var/report/ et var/log/ : ils servent de preuve du stade d'injection, distinct du stade de déclenchement.
Sources : Sansec (Forensics Team), Adobe Security Bulletin APSB26-146, The Hacker News, SOCRadar. Indicateurs à jour au 8 septembre 2026 — l'analyse de Sansec est amenée à évoluer avec de nouveaux échantillons.
