⚠ Faille critique en cours d’exploitation — à traiter immédiatement
Cette faille est activement exploitée depuis le 4 septembre 2026. Contrairement aux bulletins précédents, les correctifs de juillet et août ne protègent pas : des boutiques entièrement à jour ont été compromises. Si vous gérez une boutique Magento, appliquez le hotfix Adobe et vérifiez l’absence de porte dérobée sans attendre.
Le 7 septembre 2026, Adobe a publié en urgence, hors de son cycle mensuel habituel, le bulletin APSB26-146 pour corriger une faille classée au niveau de gravité maximal : CVE-2026-75650, score CVSS de 10.0, surnommée StyleSmuggler par la société de sécurité néerlandaise Sansec qui l’a découverte (sources : Adobe Security Bulletin APSB26-146 ; Sansec, « StyleSmuggler 0-day »). C’est le pire scénario possible pour une boutique en ligne : exécution de code à distance, sans aucune authentification, déjà exploitée en conditions réelles avant même que le correctif n’existe.
Pourquoi cette faille est différente des précédentes
Les bulletins de juillet (APSB26-73) et août (APSB26-92) que nous avons couverts ici étaient déjà sérieux. StyleSmuggler est d’une autre nature, pour une raison qui doit retenir l’attention de tout marchand Magento : être à jour de tous les patches ne suffit pas à s’en protéger.
La première victime confirmée tournait sur Magento 2.4.6-p15 avec les correctifs de juillet et août 2026 entièrement appliqués — sa propre commande security:patch-status indiquait un état sain au moment de la compromission (source : Sansec). Autrement dit, une boutique qui avait fait tout ce qu’Adobe recommandait jusqu’alors a quand même été piratée. Sansec a reproduit la chaîne d’attaque complète, sans authentification, sur des installations propres de Magento Open Source 2.4.7, 2.4.8 et 2.4.9 — la faille n’est donc pas liée à une version obsolète particulière.
Catégorie : neutralisation incorrecte d’éléments dans un moteur de template (CWE-1336)
Impact : exécution de code arbitraire sur le serveur
Authentification requise : aucune
Vecteur CVSS : AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — attaque réseau, faible complexité, aucun privilège, aucune interaction utilisateur
Priorité Adobe : 1 (la plus élevée)
Comment fonctionne l’attaque
StyleSmuggler détourne le système de templates de Magento lui-même. D’après l’analyse technique de Sansec, l’attaque se déroule en deux temps.
Injection du code (« empoisonnement »)
L’attaquant manipule les propriétés « styles » dans une requête GraphQL pour injecter du code PHP malveillant dans un fichier que Magento génère lors de son fonctionnement normal — par exemple un rapport d’échec de paiement. En passant par les propriétés de style, l’attaque contourne les protections existantes.
Exécution via un e-mail
Le code empoisonné est ensuite exécuté par Magento lui-même, au moment de la génération d’un e-mail de rappel de transaction échouée (« Payment Transaction Failed Reminder »). C’est le moteur de template légitime de Magento qui déclenche l’exécution du code injecté.
Point important signalé par Sansec : déplacer les sessions vers Redis ou la base de données ne bloque pas l’attaque. Un marchand a rapporté une première tentative échouée contre le stockage de session, suivie huit secondes plus tard d’une seconde tentative réussie via un fichier uploadé par les options personnalisées de Magento — le même opérateur passant simplement d’une méthode à l’autre.
Une porte dérobée qui survit au correctif
C’est l’autre raison de ne pas se contenter d’appliquer le patch. Les attaquants déposent une porte dérobée persistante — plusieurs sources rapportent un backdoor écrit en Rust, auto-actualisé, capable de se déguiser en processus système Linux et d’échapper aux scanners commerciaux (sources : The Hacker News, techtimes.com). Cette porte dérobée survit à l’application du correctif : patcher referme la porte d’entrée, mais ne supprime pas ce qui a déjà été installé si la boutique était déjà compromise.
Un détail illustre la vitesse des attaquants : selon la société néerlandaise Disrex, un serveur Magento a été compromis 50 minutes seulement après la première exploitation confirmée de StyleSmuggler, le 4 septembre à 22h20 UTC.
Quelles versions sont concernées
Toutes. Le bulletin Adobe liste l’ensemble des lignes supportées, chacune « et antérieures », jusqu’au niveau de patch d’août 2026 inclus.
Source : Adobe Security Bulletin APSB26-146, publié le 7 septembre 2026 — helpx.adobe.com/security
Ce qu’il faut faire, dans l’ordre
Appliquer le hotfix immédiatement
Adobe livre le correctif sous forme de hotfix isolé pour CVE-2026-75650 (et non d’une nouvelle version). Il s’applique en patch Composer. À déployer sans attendre le prochain cycle de maintenance planifié.
Vérifier l’absence de compromission
Patcher ne suffit pas si la boutique était déjà infectée. Il faut chercher activement les signes de porte dérobée : fichiers PHP suspects, processus inhabituels, scripts inconnus injectés côté storefront. Une boutique dont l’état de patch semblait sain a pu être compromise avant le 7 septembre.
Surveiller le storefront, pas seulement les logs serveur
Ce type de compromission ne produit pas toujours d’erreur visible ni d’alerte dans l’admin. Une surveillance du comportement réel des pages (scripts inattendus, formulaires modifiés) détecte des symptômes que les logs serveur peuvent ne pas montrer.
Ne pas confondre avec le bulletin mensuel du 8 septembre
Attention à une source de confusion : Adobe a publié deux choses coup sur coup. Le hotfix d’urgence APSB26-146 (7 septembre) pour StyleSmuggler, décrit ici, et le bulletin mensuel régulier APSB26-138 (8 septembre), qui corrige d’autres vulnérabilités sans lien et pour lesquelles Adobe indique n’avoir aucune preuve d’exploitation. Les deux sont à appliquer, mais c’est bien APSB26-146 qui relève de l’urgence absolue.
FAQ
Ma boutique était à jour de juillet et août. Suis-je protégé ?
Non. C’est la particularité de cette faille : la première victime confirmée était entièrement à jour, avec un état de patch sain. Le hotfix APSB26-146 est nécessaire en plus des correctifs précédents. Et si votre boutique a pu être exposée entre le 4 et le 7 septembre, il faut vérifier qu’elle n’a pas déjà été compromise.
Appliquer le patch supprime-t-il une éventuelle infection ?
Non. Le patch referme la faille mais ne retire pas une porte dérobée déjà installée. Si votre boutique a été compromise avant l’application du correctif, le code malveillant peut persister. Un audit de compromission est indispensable en complément du patch, pas en option.
Un pare-feu applicatif suffit-il en attendant ?
Un WAF spécialisé peut bloquer les variantes connues de l’attaque, et Sansec indique que son pare-feu Shield bloque celles observées à ce jour. Mais la surface d’attaque est large et les opérateurs changent leurs charges plusieurs fois par jour — un WAF est une mesure de mitigation utile, pas un substitut au correctif officiel, qui reste indispensable.
Votre boutique Magento est-elle patchée — et surtout, saine ?
Face à StyleSmuggler, appliquer le hotfix n’est que la moitié du travail. On applique le correctif, on audite votre boutique pour détecter une éventuelle porte dérobée, et on sécurise ce qui doit l’être.
Faire vérifier ma boutique →