Adobe a corrigé CVE-2026-75650, une vulnérabilité critique d’Adobe Commerce et de Magento Open Source que des attaquants exploitaient avant qu’un correctif soit disponible. Cette faille d’exécution de code à distance sans authentification affiche un score CVSS de 10,0 et est suivie par l’entreprise de sécurité Sansec sous le nom de « StyleSmuggler ».
Le correctif VULN-39341 comble la vulnérabilité, mais les boutiques compromises avant l’installation du correctif peuvent toujours contenir des malwares persistants ou des identifiants exposés. Adobe demande aux marchands de renouveler non seulement les clés de chiffrement Commerce, mais aussi les mots de passe, les jetons, les identifiants de paiement, les identifiants de base de données et autres secrets auxquels les attaquants ont pu accéder.
L’avis APSB26-146 d’Adobe confirme l’exploitation dans la nature et indique qu’un attaquant n’a besoin d’aucune authentification pour exécuter du code arbitraire. Les équipes de défense ne doivent pas évaluer la faille uniquement d’après son score CVSS car l’exploitation active et la persistance renforcent l’urgence au-delà de la gravité théorique.
Comment StyleSmuggler compromet les boutiques Magento
Sansec indique que la première exploitation confirmée a eu lieu à 22 h 20 UTC le 4 septembre. Sansec a ensuite 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.
L’exploit abuse du système de modèles de Magento. Les attaquants injectent d’abord du code PHP dans des données que Magento traite ultérieurement, puis déclenchent l’e-mail « Rappel d’échec de transaction de paiement » de la plateforme afin que Magento exécute le code empoisonné.
Aucun employé ni client n’a besoin d’ouvrir l’e-mail. Le code malveillant s’exécute lorsque Magento génère le message, et l’attaque peut réussir même si la livraison échoue.
Une attaque réussie peut installer un malware en dehors de la racine web. Sansec a d’abord observé un implant Rust dissimulé derrière le nom de processus [kworker/u:8:0].fc-cache D’autres versions ont ensuite utilisé chronyd et enfin
La persistance a également évolué entre les variantes de l’implant. Certaines versions créaient des tâches cron qui relançaient le malware, tandis qu’une variante chronyd redémarrait sans aucune entrée cron. Un crontab vide ne prouve donc pas qu’un hôte est sain.
Disrex, qui a enquêté directement sur des serveurs Magento compromis, a signalé qu’un serveur administré avait été touché seulement 50 minutes après la première exploitation confirmée de StyleSmuggler. Le serveur était entièrement corrigé contre les vulnérabilités connues jusque-là.
Lors des attaques SessionReaper en 2025, les attaquants avaient également déployé des web shells PHP pour conserver l’accès après l’exploitation de Magento, ce qui donne aux défenseurs une raison supplémentaire de rechercher les mécanismes de persistance après avoir fermé le point d’entrée initial.
Qui doit installer le correctif Adobe
Adobe répertorie les branches Adobe Commerce concernées de 2.4.4 à 2.4.9, y compris leurs versions d’août 2026 et les versions antérieures de ces branches. Les versions Adobe Commerce B2B des branches concernées 1.3.3 à 1.5.3 sont également incluses.
Les branches Magento Open Source 2.4.6, 2.4.7, 2.4.8 et 2.4.9 sont concernées.
Adobe demande à ses clients d’installer le correctif Composer VULN-39341 correspondant à leur version. Pour Adobe Commerce on Cloud, Adobe fournit également une commande de Quality Patches Tool permettant de vérifier que le correctif affiche un état Applied.
La mise à jour de sécurité Commerce de septembre 2026 ne supprime pas cette obligation. Dans APSB26-138, Adobe demande expressément à ses clients d’appliquer le correctif CVE-2026-75650 en plus des mises à jour de sécurité de septembre.
Adobe indique que le correctif a été testé sur les versions listées d’août 2026. Il peut fonctionner sur d’autres configurations prises en charge, mais Adobe n’a pas vérifié ces combinaisons.
Ce que les défenseurs doivent rechercher après l’application du correctif
Sansec a observé plusieurs variantes d’implants depuis le début de la campagne. Les défenseurs ne doivent donc pas se fier à un seul nom de fichier ou de processus.
| Indicateur | Éléments à examiner |
|---|---|
[kworker/u:8:0] | Processus utilisant un nom de type thread noyau sous un utilisateur Magento non root |
fc-cache | Processus ou binaire inattendu sous ~/.cache/fontconfig/ ou dans des répertoires temporaires |
chronyd | Processus chronyd inattendu sous /tmp/.chrony-* plutôt que dans le chemin système normal |
gvfsd-user | Binaire sous ~/.local/share/.gvfsd/ |
| Modifications de cron | Tâches lançant gvfsd-user, fc-cache, ou chronyd, y compris des modifications directes des fichiers spool de cron |
| Trafic sur le port UDP 123 | Trafic sortant inhabituel, ressemblant à du NTP, depuis l’hôte Magento |
PHP sous pub/media | Fichiers PHP inattendus pouvant indiquer un web shell secondaire |
Sansec indique qu’un autre attaquant a également utilisé l’accès obtenu par StyleSmuggler pour installer un web shell PHP dans le cache des images produit. Cette charge utile n’avait aucun lien avec l’implant Rust principal ; trouver ou supprimer une famille de malwares connue n’exclut donc pas l’existence d’une compromission supplémentaire.
Sansec indique qu’eComscan peut détecter les processus d’arrière-plan StyleSmuggler connus et les arrêter pour les clients de Shield. L’entreprise a continué d’améliorer la détection à mesure que de nouvelles variantes d’implants apparaissaient.
Sansec n’a pas signalé d’éléments prouvant que la porte dérobée principale a servi à exécuter des commandes d’attaquants, mais les hôtes déjà compromis doivent tout de même faire l’objet d’une enquête.
Pendant la phase de confinement, les équipes doivent réduire la surface d’attaque inutile en limitant les services exposés et en restreignant les connexions sortantes lorsque cela est possible. Cela peut empêcher les implants d’atteindre l’infrastructure de commande et de contrôle pendant l’examen de l’hôte.
Pourquoi Adobe exige le renouvellement des identifiants
Adobe avertit que la modification de la clé de chiffrement Commerce n’invalide pas les secrets qu’un attaquant a pu obtenir auparavant.
Après l’application du correctif, la procédure de remédiation d’Adobe prévoit de placer la boutique en mode maintenance, de désactiver cron et de renouveler les éléments suivants :
- Clés de chiffrement Commerce et mots de passe administrateur
- Jetons d’intégration REST, SOAP et GraphQL
- Secrets des clients OAuth
- Identifiants des passerelles de paiement auprès de fournisseurs tels que Stripe, Braintree, Adyen et PayPal
- Identifiants de base de données
- Clés SSH et clés de déploiement
- Identifiants des comptes de service privilégiés
- Clés d’API d’expédition, de fiscalité et d’autres services tiers
Adobe demande ensuite aux marchands de vider les caches, de rétablir l’exécution de cron et de désactiver le mode maintenance une fois le renouvellement terminé.
Les identifiants de paiement et ceux des services tiers doivent être modifiés auprès du fournisseur externe, et pas uniquement dans Adobe Commerce. Si un attaquant a déjà copié un secret valide, modifier la manière dont Commerce chiffre sa copie stockée ne révoque pas cet identifiant.
Les boutiques exposées avant le correctif du 7 septembre doivent traiter CVE-2026-75650 comme un incident de sécurité, et pas seulement comme une tâche de mise à jour. Appliquez le correctif, vérifiez-le lorsque Adobe fournit un contrôle pris en charge, recherchez les mécanismes de persistance, renouvelez les identifiants potentiellement exposés et examinez toute activité suspecte avant de remettre la boutique en fonctionnement normal.
À lire aussi : Google a corrigé CVE-2026-85046 après avoir confirmé son exploitation dans la nature, ce qui en fait le sixième zero-day de Chrome corrigé en 2026.