CVE-2026-75650 : Adobe corrige une vulnérabilité zero-day critique exploitée activement dans Magento pour déployer des portes dérobées

Adobe a publié une mise à jour de sécurité d’urgence pour corriger une vulnérabilité de gravité maximale dans Adobe Commerce et Magento Open Source, que les attaquants exploitent déjà dans la nature. Répertoriée sous le nom de CVE-2026-75650 et notée 10.0 sur l’échelle CVSS, la faille permet l’exécution de code à distance non authentifié sur les serveurs e-commerce vulnérables.

La vulnérabilité, surnommée StyleSmuggler par l’entreprise de sécurité e-commerce Sansec, exploite la fonctionnalité de traitement de template de Magento pour injecter et exécuter du code PHP malveillant. Les attaques ont été confirmées pour la première fois le 4 septembre 2026, plusieurs jours avant qu’Adobe ne publie son correctif d’urgence le 7 septembre.

Les acteurs de menace ont déjà utilisé le zero-day pour déployer une porte dérobée Linux basée sur Rust et, dans des attaques distinctes, un shell web PHP capable d’exécuter des commandes PHP arbitraires. Étant donné que l’exploitation ne nécessite pas de compte Magento valide ni d’interaction utilisateur, les boutiques exposées à internet utilisant des versions vulnérables doivent être considérées comme des cibles prioritaires pour le patching et l’enquête rétrospective.

Analyse du CVE-2026-75650

Adobe classe la vulnérabilité comme CWE-1336 : Neutralisation incorrecte d’éléments spéciaux utilisés dans un moteur de template. Son vecteur CVSS indique une exploitation basée sur le réseau, une faible complexité d’attaque, aucun privilège et aucune interaction utilisateur, avec un impact potentiellement élevé sur la confidentialité, l’intégrité et la disponibilité.

Les détails les plus importants pour le CVE-2026-75650 concernent la façon dont Magento transforme les données contrôlées par les attaquants en PHP exécutable lors du traitement normal de l’application. StyleSmuggler abuse des directives de template et de la fonctionnalité interne d’injection de dépendances plutôt que de s’appuyer sur une extension malveillante ou un compte administrateur.

À un niveau élevé, l’attaque connue suit deux étapes. Tout d’abord, du contenu PHP contrôlé par l’attaquant est écrit dans un fichier auquel Magento peut accéder plus tard, tel qu’un journal d’application ou un rapport. Une deuxième requête provoque ensuite l’atteinte par la chaîne de traitement de template de Magento à la fonctionnalité de scanner d’injection de dépendances qui charge le fichier empoisonné en utilisant include ou require_once en PHP. Étant donné que ces fonctions interprètent le PHP plutôt que de lire simplement le fichier, le code contrôlé par l’attaquant s’exécute sur le serveur.

Sansec décrit un autre aspect observable de la chaîne : les attaquants déclenchent délibérément l’email normal Rappel de transaction de paiement échouée de Magento. Le code malveillant s’exécute pendant que Magento rend le template, donc un client ou un administrateur n’a pas besoin d’ouvrir l’email. L’exploit peut même réussir lorsque la livraison de l’email échoue.

Contactez les Ventes

Le CVE-2026-75650 affecte les branches suivantes de Adobe Commerce selon le bulletin d’urgence d’Adobe :

• 2.4.9-2026-aug et antérieures
• 2.4.8-2026-aug et antérieures
• 2.4.7-2026-aug et antérieures
• 2.4.6-2026-aug et antérieures
• 2.4.5-2026-aug et antérieures
• 2.4.4-2026-aug et antérieures

Les versions B2B concernées d’Adobe Commerce incluent :

• 1.5.3-2026-aug et antérieures
• 1.5.2-2026-aug et antérieures
• 1.4.2-2026-aug et antérieures
• 1.3.4-2026-aug et antérieures
• 1.3.3-2026-aug et antérieures

Les branches de Magento Open Source jusqu’à 2.4.9-2026-aug sont également couvertes par le bulletin d’Adobe.

Sansec a reproduit indépendamment toute la chaîne d’attaque non authentifiée sur des installations propres de Magento Open Source 2.4.7, 2.4.8 et 2.4.9. Son premier client compromis confirmé fonctionnait avec Magento 2.4.6-p15 avec les mises à jour de sécurité de juillet et août appliquées, démontrant que les systèmes considérés comme totalement corrigés avant le 7 septembre étaient toujours vulnérables au zero-day.

Une fois l’exécution de code à distance obtenue, la compromission s’étend au-delà de Magento lui-même. La première campagne observée a déployé un petit implant Linux basé sur Rust qui établissait une persistance et communiquait avec l’infrastructure attaquante tout en se déguisant en activité système légitime.

Les premières versions se faisaient passer pour un processus de travail du noyau nommé :

Les versions ultérieures ont adopté des noms incluant :

fc-cache

et :

chronyd

La variante fc-cache se stockait sous ~/.cache/fontconfig/fc-cache, ajoutait une entrée cron pour redémarrer deux fois par heure et utilisait le trafic du port UDP 123 conçu pour ressembler à des communications NTP. Sansec a signalé que les domaines associés résolvaient à 185.157.160.251 au 7 septembre.

Un attaquant distinct a été observé exploitant la même vulnérabilité pour livrer un petit programme d’installation PHP. Cette charge utile créait un shell web PHP caché sous un chemin ressemblant à :

pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php

Le shell renvoyait normalement une réponse HTTP 404, mais les requêtes contenant l’en-tête X-Cache-Token requis pouvaient fournir du code PHP via un paramètre POST pour exécution.

Ces observations montrent que StyleSmuggler n’est pas lié à une seule famille de malware ou acteur de menace. Plusieurs adversaires peuvent indépendamment utiliser la RCE sous-jacente pour déployer leur outil de persistance et de post-compromission préféré.

Sansec a enregistré la première exploitation confirmée le 4 septembre à 22h20 UTC. Un autre serveur Magento enquêté par Disrex a été compromis environ 50 minutes plus tard. Adobe a publié le bulletin APSB26-146 et le correctif d’urgence officiel le 7 septembre, confirmant que l’exploitation était déjà en cours dans la nature.

Sansec et Disrex ont publié des informations techniques détaillées sur la chaîne sous-jacente mais ont intentionnellement retenu une requête entièrement armée qui rendrait l’exploitation triviale à reproduire.

Utile Les IOC de CVE-2026-75650 incluent des processus et fichiers suspects associés à l’implant Rust, des fichiers PHP inhabituels sous les répertoires média de Magento, une activité de rappel de transaction de paiement échouée inattendue, et l’infrastructure identifiée par Sansec. Les défenseurs doivent également rechercher du contenu de rapport ou de journal malveillant plutôt que de limiter les enquêtes à la racine web de Magento.

Atténuation du CVE-2026-75650

Adobe a classé l’APSB26-146 comme Priorité 1 et instruit les clients affectés d’appliquer immédiatement le correctif dédié VULN-39341 . Le package de correctif officiel est distribué via le dépôt Magento d’Adobe pour les versions de Commerce et Magento Open Source affectées.

Adobe instruit également les clients de faire tourner leurs clés de chiffrement après l’application du correctif. Ceci est particulièrement important pour les magasins qui étaient exposés avant le 7 septembre car l’exécution de code arbitraire réussie peut avoir permis aux attaquants d’accéder à des secrets d’application et à une configuration serveur sensible.

La détection du CVE-2026-75650 devrait donc commencer par trois questions :

1. Le magasin était-il accessible depuis Internet entre le 4 septembre et l’installation du correctif d’Adobe ?
2. Le VULN-39341 a-t-il été appliqué avec succès ?
3. Y a-t-il des signes que des processus PHP ou natifs ont été lancés avant la remédiation ?

Pour détecter l’exploitation ou l’activité de post-compromission du CVE-2026-75650, les équipes de sécurité devraient rechercher :

• Pics inattendus d’emails de rappel de transaction de paiement échouée
• Contenu PHP suspect dans les journaux de Magento ou fichiers sous var/report/
• Fichiers de rapport contenant des chaînes x_trace_ inhabituelles
• Processus se faisant passer pour [kworker/u:8:0], fc-cache, ou chronyd
• ~/.local/share/.gvfsd/ ou ~/.cache/fontconfig/fc-cache
• Jobs cron suspects redémarrant des binaires inconnus
• Fichiers PHP inattendus sous pub/media/
• Web shells sous pub/media/catalog/product/cache/
• Trafic sortant vers l’infrastructure connue de StyleSmuggler
• Communications UDP/123 anormales depuis l’hôte de l’application Magento
• Requêtes HTTP inattendues impliquant un comportement de traitement de template inhabituel
• Nouveaux utilisateurs d’application, changements de credentials, ou configuration de serveur modifiée après une activité web suspecte

Les administrateurs ne doivent pas supposer que la suppression d’un fichier suspect du répertoire Magento élimine la compromission. Dans les incidents enquêtés, le malware se relocalisait en dehors du webroot, créait une persistance basée sur cron, continuait de s’exécuter à partir de fichiers supprimés, et pouvait recréer des parties de sa persistance après suppression.

Le processus d’atténuation du CVE-2026-75650 devrait donc inclure une réponse aux incidents pour les magasins qui étaient publiquement accessibles avant le patching. Si des indicateurs de compromission sont découverts, isolez l’hôte, préservez les preuves judiciaires, terminez les processus malveillants, identifiez les mécanismes de persistance, examinez les changements du système de fichiers, et faites tourner les credentials et secrets accessibles depuis le serveur affecté.

Une attention particulière devrait être accordée à :

• Credentials des administrateurs Magento
• Clés de chiffrement Adobe Commerce
• Credentials de base de données
• Secrets d’API et d’intégration
• Credentials de paiement et de services tiers
• Credentials SSH
• Jetons de cloud ou d’hébergement accessibles depuis l’hôte de l’application

Les équipes de sécurité devraient également valider l’intégrité des fichiers d’application et extensions Magento et enquêter sur l’activité réseau sortante pour détecter les signes que l’implant a communiqué avec une infrastructure de commande et de contrôle externe.

Étant donné que les premières attaques de StyleSmuggler sont survenues avant qu’un patch officiel ou que les signatures de détection publique ne soient disponibles, le simple fait de confirmer qu’un magasin est maintenant à jour n’établit pas qu’il n’a jamais été compromis. Tout système vulnérable exposé sur internet fonctionnant pendant la fenêtre zero-day du 4 au 7 septembre doit faire l’objet d’un examen historique.