Si vous gérez ou développez des boutiques sous Magento 2 ou Adobe Commerce, ce que je vais dire mérite votre attention immédiate. Une faille critique est activement exploitée depuis le 4 septembre 2026.
StyleSmuggler — ce qu’il faut savoir
La faille CVE-2026-75650, surnommée « StyleSmuggler » par les chercheurs de Sansec (spécialistes sécurité e-commerce), touche Adobe Commerce et Magento Open Source de la 2.4.4 à la 2.4.9 incluse, tous niveaux de patch jusqu’aux versions d’août 2026.
Son score CVSS est 10.0 — le maximum. C’est une RCE (exécution de code à distance) non authentifiée, sans aucune action utilisateur requise, classée CWE-1336 (« Improper Neutralization of Special Elements Used in a Template Engine »).
Détail technique de la chaîne d’exploitation
L’attaque se déroule en plusieurs étapes, bien plus subtiles qu’un simple champ mal filtré :
Requête forgée sur /graphql : l’attaquant envoie une requête POST contenant une directive de template Magento (de type {{block class=...}}) accompagnée d’un paramètre styles pointant vers un fichier local, typiquement ../var/log/system.log.
Empoisonnement de log : ce paramètre styles sert de vecteur pour écrire du code PHP arbitraire dans ce fichier de log — c’est le « smuggling » qui donne son nom à la faille, le contenu malveillant étant dissimulé dans des données que le moteur de template ne s’attend pas à voir exécutées.
Détournement du compilateur DI : une seconde requête déclenche, via une chaîne d’injection d’objets, des classes du compilateur de dependency injection de Magento — normalement réservées à la commande CLI bin/magento setup:di:compile — pour qu’elles réalisent un include/require_once à chemin variable sur le fichier de log déjà empoisonné. Le PHP injecté s’exécute alors côté serveur.
Plusieurs analyses associent aussi le déclenchement à la génération de l’email « Payment Transaction Failed Reminder », qui emprunte le même chemin de rendu de template vulnérable — l’exécution a donc lieu même si l’email n’atteint jamais une boîte de réception.
La charge utile observée dans la nature est sérieuse : un backdoor écrit en Rust, déguisé en thread noyau Linux ([kworker/u:8:0]), avec persistance via cron. Des variantes plus récentes exfiltrent des données système via du trafic UDP déguisé en NTP. Un web shell PHP est également déposé dans plusieurs cas pour garder un contrôle interactif.
Patcher ne suffit pas si vous êtes déjà compromis
C’est le point crucial. Adobe a publié le patch d’urgence le 7 septembre 2026, bulletin de sécurité officiel APSB26-146 (voir aussi l’annonce sur Adobe Commerce Knowledge Base). Mais appliquer le patch ferme la vulnérabilité sans nettoyer un site déjà compromis — backdoor, entrées cron et web shell restent actifs.
Adobe recommande en plus, après application du patch, de régénérer vos clés de chiffrement et les identifiants associés, par précaution si le serveur a pu être compromis avant le patch.
Actions à prendre maintenant
Appliquer le patch officiel : bulletin APSB26-146, fichier VULN-39341-composer-patches.zip à télécharger depuis repo.magento.com et à appliquer via Composer.
Vérifier la compromission : chercher des processus suspects (notamment [kworker/u:8:0] avec un comportement inhabituel), des entrées cron inconnues, des fichiers web shell récents dans le webroot, et examiner var/log/system.log et var/report/ pour des traces de code injecté.
Régénérer les clés de chiffrement et identifiants une fois le patch appliqué, comme recommandé par Adobe.
Si vous trouvez des traces de compromission, considérer le serveur comme compromis et traiter en conséquence (isolation, analyse forensique, reconstruction si nécessaire).
IA et découverte de failles : le rythme s’accélère
Ce qui me frappe avec StyleSmuggler — et ce n’est pas un cas isolé — c’est la vitesse à laquelle ce type de faille émerge aujourd’hui. Les chercheurs en sécurité utilisent de plus en plus des outils d’analyse de code automatisée, de fuzzing assisté par IA et de modèles de langage pour passer au crible des milliers de lignes de code en un temps record. C’est une très bonne chose pour la détection. Le problème c’est que les attaquants ont accès aux mêmes outils.
On commence à voir des failles découvertes et exploitées dans une fenêtre de temps beaucoup plus courte qu’avant. Ici, exploitation active le 4 septembre, patch le 7 — trois jours de fenêtre d’exploitation avant même que la plupart des équipes aient eu le temps de réagir.
Du coup la vraie question, c’est : dans un contexte où la découverte de failles s’accélère grâce à l’IA, est-ce que le modèle « je patche quand ça sort » est encore suffisant pour protéger une boutique en production, ou est-ce qu’il faut repenser complètement l’approche — surveillance active, durcissement en amont, détection comportementale — pour rester dans la course ?
Pas de réponse simple, mais ça vaut le coup d’y réfléchir 🙂
N’hésitez pas à partager vos retours en commentaire, et surtout à me dire si vous avez eu des sites impactés.
Articles Relatif à Magento : StyleSmuggler, la faille zero-day CVSS 10 activement exploitée
