StyleSmuggler frappe Magento : le correctif ne suffit pas à lui seul

Adobe a publié le 7 septembre 2026 le hotfix VULN-39341 contre StyleSmuggler, une faille d’exécution de code à distance sans authentification déjà exploitée depuis le 4 septembre. L’analyse de Tenable confirme cette fenêtre de trois jours sans correctif et conclut qu’une boutique restée accessible pendant cette période nécessite aussi une réponse à incident.

Installer le hotfix ferme le vecteur connu, mais n’efface ni un implant, ni une porte dérobée, ni des identifiants copiés avant la mise à jour. Pour une installation potentiellement exposée, la remédiation doit donc enchaîner quatre opérations distinctes : choisir le correctif adapté, vérifier son application, renouveler les clés et identifiants concernés, puis rechercher des indices de compromission.

La version installée détermine le correctif

Le périmètre publié demande une lecture précise. La matrice d’Adobe, actualisée le 11 septembre, classe comme affectées les branches Adobe Commerce 2.4.4 à 2.4.9, Magento Open Source 2.4.6 à 2.4.9 et plusieurs branches Adobe Commerce B2B allant de 1.3.3 à 1.5.3. Elle fournit plusieurs archives VULN-39341 selon la révision exacte et précise que le correctif est compatible avec les versions Adobe Commerce et Magento Open Source comprises entre 2.4.4 et 2.4.7.

Le périmètre Magento Open Source n’est toutefois pas formulé de la même façon par tous les acteurs. L’enquête technique de Sansec, mise à jour le 11 septembre, indique que les versions 2.4.4 à 2.4.9 sont affectées, situe la première exploitation confirmée au 4 septembre et attribue à la vulnérabilité un score CVSS de 10,0. L’écart porte donc sur les branches Open Source 2.4.4 et 2.4.5, pas sur les versions Adobe Commerce portant les mêmes numéros.

• Adobe Commerce 2.4.4 à 2.4.9 : relever la version complète et son niveau de patch, puis sélectionner l’archive VULN-39341 correspondante dans la matrice officielle.
• Magento Open Source 2.4.6 à 2.4.9 : traiter l’installation comme affectée et utiliser le fichier prévu pour sa révision exacte.
• Magento Open Source 2.4.4 ou 2.4.5 : ne pas déduire une absence de risque de leur omission dans la liste synthétique des produits affectés. La divergence avec l’analyse de terrain et la présence de correctifs compatibles justifient une validation auprès d’Adobe ou de l’intégrateur.
• Adobe Commerce B2B : vérifier à la fois la version du module B2B et celle de l’environnement Commerce sous-jacent.
• Version hors support : l’absence de ligne dans la matrice ne prouve pas que la faille est impossible à exploiter. Un correctif tiers non évalué ne doit pas être assimilé au hotfix officiel.

Ce que le hotfix bloque, sans réparer le passé

StyleSmuggler détourne le traitement de propriétés liées aux styles dans le moteur de modèles Magento. Le contenu contrôlé par l’attaquant peut être écrit sur disque sous forme de code PHP, puis exécuté lorsque la plateforme produit une notification transactionnelle d’échec de paiement. Aucun compte client ou administrateur n’est nécessaire pour déclencher la chaîne.

Le hotfix corrige ce chemin d’exécution pour les requêtes futures. Il ne supprime pas les fichiers déposés, les processus persistants, les tâches cron ajoutées ou les secrets obtenus avant son installation. Le choix de Redis, d’une base de données ou de fichiers pour stocker les sessions ne neutralise pas non plus la chaîne décrite.

Cette limite explique le titre : le correctif est indispensable, mais son installation ne démontre pas que l’hôte était sain auparavant. Elle ne garantit pas davantage qu’un attaquant ayant déjà obtenu un accès persistant en a été expulsé.

Correctif, contrôle, rotation : l’ordre compte

La séquence doit d’abord empêcher une nouvelle exploitation, puis remplacer les secrets potentiellement lisibles. Renouveler les identifiants avant de fermer la faille risquerait d’exposer immédiatement leurs nouvelles valeurs.

1. Appliquer le fichier VULN-39341 correspondant à la version complète de l’installation, après une validation en préproduction lorsque l’environnement le permet.
2. Contrôler la présence réelle du hotfix. Sur Adobe Commerce on Cloud, la commande vendor/bin/magento-patches -n status, filtrée sur « 39341 » et « Status », doit faire apparaître l’état « Applied ».
3. Activer le mode maintenance et interrompre les tâches cron avant la rotation des secrets.
4. Renouveler la clé de chiffrement, les mots de passe administrateur, les jetons REST, SOAP et GraphQL, les secrets OAuth, les identifiants des passerelles de paiement, les accès aux bases de données, les clés SSH et de déploiement ainsi que les clés des extensions connectées.
5. Régénérer chaque identifiant auprès du service qui l’a émis. Une modification enregistrée uniquement dans Commerce ne révoque pas une valeur déjà copiée.
6. Vider les caches, réactiver cron, quitter le mode maintenance et redéployer l’environnement Cloud si le renouvellement des accès à la base de données l’exige.

La rotation de la seule clé de chiffrement reste insuffisante : elle protège les nouvelles écritures, mais n’invalide pas automatiquement les jetons ou identifiants externes que l’ancienne clé permettait de déchiffrer.

Rechercher les traces laissées avant le 7 septembre

Une boutique accessible avant l’application effective du hotfix doit être considérée comme exposée, sans être déclarée compromise en l’absence de preuve. L’examen doit comparer l’hôte à un état de référence fiable et couvrir les processus, tâches planifiées, fichiers créés ou modifiés, comptes administratifs, journaux web, intégrations et connexions sortantes.

Les indicateurs publiés comprennent notamment des processus malveillants déguisés sous les noms « kworker/u:8:0 », « fc-cache » ou « chronyd », des fichiers cachés dans le répertoire personnel du compte exécutant la boutique et des implantations dans des répertoires temporaires. Ces noms peuvent imiter des composants Linux légitimes : leur seule présence ne suffit donc pas, mais un chemin inhabituel, un propriétaire inattendu, une tâche cron associée ou un trafic sortant anormal renforcent le signal.

Il faut aussi inspecter les fichiers PHP inattendus sous le cache des médias et les rapports contenant des marqueurs anormaux. L’absence d’une signature connue ne garantit pas un système sain, car plusieurs charges utiles et mécanismes de persistance ont été observés au cours de la campagne.

Le statut « Applied » prouve que le hotfix est reconnu ; il ne clôt pas un incident antérieur. À ce stade, une remédiation complète repose sur des preuves séparées : le bon fichier est installé, son état est contrôlé, les secrets exposables ont été renouvelés à leur source et les indicateurs publiés ont été recherchés sans laisser de persistance connue sans traitement.

À lire aussi:

• TikTok Creator Rewards : une minute ne suffit pas pour être payé
• Activer la monétisation YouTube : le seuil ne suffit pas pour être accepté
• Résumer un anime ne suffit pas : la frontière du fair use se resserre