StyleSmuggler : la faille 0-day Magento qui exécute du code sans authentification
Publié le
Sansec a repéré la campagne le 4 septembre 2026 à 22 h 40 UTC et reproduit la chaîne complète en quelques heures sur des installations propres. La faille, baptisée StyleSmuggler, donne à un attaquant non authentifié l’exécution de code à distance sur la boutique. Adobe a publié un correctif le 7 septembre 2026 (hotfix APSB26-146, priorité 1) ; la faille, désormais CVE-2026-75650, est notée 10 sur 10.
Corrigé par Adobe le 7 septembre 2026 (hotfix APSB26-146)
Que fait concrètement cette faille ?
StyleSmuggler injecte du code dans le système de gabarits (templates) de Magento. En passant par les propriétés `styles`, la charge contourne les garde-fous déjà en place sur le moteur de rendu.
Aucun compte, aucun mot de passe, aucune interaction d’un administrateur ne sont nécessaires. C’est le pire scénario possible pour une boutique en ligne : un inconnu obtient l’exécution de code sur le serveur qui traite les paiements.
Comment l’attaque se déroule-t-elle ?
L’exploitation se joue en deux temps. Premier temps : l’attaquant empoisonne le gabarit, par exemple en provoquant volontairement un rapport d’échec.
Second temps : il déclenche l’e-mail standard « Payment Transaction Failed Reminder » de Magento. Le code empoisonné s’exécute pendant que Magento fabrique le message, côté serveur. L’e-mail n’a même pas besoin d’être ouvert par un destinataire.
Sansec a reproduit la chaîne complète, non authentifiée, sur des installations neuves de Magento Open Source 2.4.7, 2.4.8 et 2.4.9.
Qu’est-ce que ça coûte à un commerçant ?
Une exécution de code non authentifiée mène directement au dépôt d’un webshell, à l’implantation d’un skimmer de cartes bancaires sur la page de paiement (Magecart), et à l’exfiltration de la base clients.
Entre les premières attaques (4 septembre) et le correctif Adobe (7 septembre), la seule variable sous votre contrôle était votre temps d’exposition. Le hotfix existe désormais, mais il reste à déployer sur chaque boutique - et chaque jour de retard compte.
Que faire dès aujourd’hui ?
Inventoriez vos versions Magento et Adobe Commerce, y compris les environnements de préproduction exposés publiquement : ils sont ciblés par les mêmes scans automatisés.
Surveillez l’apparition de fichiers PHP dans les dossiers média et les modifications de gabarits. Un blocage ne remplace pas un audit : une boutique déjà compromise le reste après la mise en place d’un filtre.
Filtrez la chaîne d’exploitation en amont, pour tenir jusqu’au correctif éditeur : c’est exactement le rôle d’un patch virtuel.
Qui est concerné ?
- Magento Open Source et Adobe Commerce 2.4.4 à 2.4.9 concernés
- CVE-2026-75650, CVSS 10 (maximum)
- Correctif Adobe le 7 septembre 2026 (hotfix APSB26-146) ; les versions antérieures à 2.4.4 nécessitent un rétroportage
- Exploitation active dès le 4 septembre, divulgation Sansec le 5 septembre 2026
Comment AtriShield bloque-t-il la faille ?
Patch virtuel (Business et Enterprise) : la faille est neutralisée à l’entrée de votre serveur, sans modifier votre application et sans attendre la fenêtre de maintenance. Des métadonnées de sécurité remontent à votre console.
- ✓Patch virtuel appliqué à l’entrée : les requêtes portant la charge d’injection sont coupées avant d’atteindre Magento.
- ✓Les deux étapes sont couvertes : l’empoisonnement du gabarit et le déclenchement du rendu de l’e-mail.
- ✓Aucune modification de votre code, de vos gabarits ni de votre hébergeur. Rien à redéployer, aucune interruption de service.
- ✓Adobe a publié le correctif le 7 septembre : vous appliquez le hotfix APSB26-146 à froid, dans votre fenêtre de maintenance, pendant qu’AtriShield couvre l’intervalle.
Sources
- Sansec - StyleSmuggler: Magento and Adobe Commerce 0-day RCE (CVE-2026-75650)
- Adobe - Security bulletins for Magento (APSB26-146)
Analyse publiée par Atrilya Solutions à partir de publications de sécurité publiques. Les liens ci-dessus renvoient aux sources d’origine.