Magento CVE-2026-75650 : RCE non authentifiée, CVSS 10

Qu'est-ce que la CVE-2026-75650 ?

C'est une injection dans le système de templates de Magento (CWE-1336) qui permet à un attaquant non authentifié d'exécuter du code PHP sur le serveur. Sansec, qui l'a découverte et baptisée StyleSmuggler, explique qu'elle passe par les propriétés styles, traitées comme de simples données de mise en page, et qu'elle contourne des protections existantes. Adobe indique avoir connaissance d'une exploitation visant des marchands Adobe Commerce.

Comment l'exploitation se déroule-t-elle ?

En deux étapes, d'après Sansec.

1. Empoisonner un fichier ou un journal avec du code PHP, par exemple en provoquant un rapport d'erreur. Dans une variante, du PHP est envoyé dans la chaîne de requête de /paypal/transparent/response/, que Magento enregistre dans var/report/<sha256>.
2. Faire exécuter le contenu empoisonné par Magento. Le déclencheur principal est l'e-mail standard « Payment Transaction Failed Reminder » : le code s'exécute pendant le rendu du template, que l'e-mail soit réellement envoyé ou non. Une variante passe par une requête vers /graphql avec styles[first] pointant vers le rapport empoisonné. Des tentatives ultérieures ont visé var/log/system.log, var/log/exception.log et des fichiers de session.

Déplacer les sessions vers Redis ou la base de données n'arrête pas l'attaque. Les charges utiles expirent environ trois minutes après l'injection.

Quelle chronologie ?

• 23 août 2026 : sondages infructueux de l'attaquant.
• 4 septembre vers 22 h 20 UTC : première exploitation confirmée ; un serveur Magento signalé compromis une cinquantaine de minutes après, d'après The Hacker News.
• 5 septembre : Sansec reproduit la chaîne sur des installations propres 2.4.7, 2.4.8 et 2.4.9 et publie son analyse.
• 7 septembre : Adobe publie APSB26-146 et le correctif VULN-39341, priorité 1, CVSS 10,0.
• 8 septembre : ajout au KEV de la CISA, échéance fédérale au 11 septembre.
• 10 septembre : règles WAF de Cloudflare et Imperva.

Quelles versions sont concernées ?

Sansec indique que toutes les versions de 2.4.4 à 2.4.9 sont affectées. Selon The Hacker News, la liste d'Adobe est : Adobe Commerce 2.4.4 à 2.4.9, Adobe Commerce B2B 1.3.3, 1.3.4, 1.4.2, 1.5.2 et 1.5.3, Magento Open Source 2.4.6 à 2.4.9, dans chaque cas « 2026-aug et antérieures ». Sansec a observé une boutique en 2.4.6-p15, à jour des correctifs de juillet et d'août, qui a été touchée : un niveau de correctifs courant n'apporte aucune protection. Adobe ne fournit pas de correctif pour les branches hors support (2.2, 2.3, 2.4.0 à 2.4.3). Passer simplement à la version 2.4.9 ne suffit pas : le correctif VULN-39341 est nécessaire.

Quels logiciels malveillants ont été observés ?

Sansec a trouvé plusieurs charges : une porte dérobée en Rust (fc-cache, puis chronyd) qui utilise un trafic UDP imitant le protocole NTP pour sa commande et son contrôle, un relais gs-netcat, le RAT WraithC2, une inclusion de fichier distant déclenchée par un cookie et un skimmer encodé en base64 dans core_config_data. Un second acteur, distinct, a déposé un dropper PHP et un web shell dans le cache des images de produits. The Hacker News mentionne aussi la porte dérobée Rust et le web shell PHP.

Que faire, dans l'ordre ?

1. Appliquez le correctif VULN-39341 (APSB26-146) à votre version, via le correctif Composer, et vérifiez-le avec la commande d'état des correctifs. Les rétroportages non officiels pour les anciennes branches se testent d'abord sur un environnement de préproduction.
2. Renouvelez la clé de chiffrement et tout ce qu'elle protège : mots de passe d'administration, jetons d'API et d'intégration, secrets OAuth, clés de passerelles de paiement, identifiants de base de données, clés SSH et de déploiement. Faites-le à la source, pas seulement dans Magento. Adobe indique que correctif et renouvellement sont tous deux nécessaires.
3. Recherchez une compromission : corriger ne nettoie pas une boutique déjà infectée.
4. Bloquez les attaques avec un WAF à jour, en complément et non en remplacement du correctif.
5. Limitez l'e-mail déclencheur si possible (un plugin communautaire peut empêcher les e-mails de rappel de paiement échoué) et surveillez les rafales de ces e-mails.

Que chercher pour savoir si une boutique est compromise ?

Sansec publie des indicateurs et des commandes de recherche. Les principaux :

• fichiers PHP sous pub/media, notamment pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php ;
• fichiers var/report/<sha256> contenant le marqueur x_trace_ et entrées InvalidArgumentException de Laminas dans var/log/exception.log ;
• tâches cron inattendues, processus nommés kworker, fc-cache ou chronyd dont l'emplacement ou le parent ne correspond pas, fichiers cachés sous /tmp et dans le répertoire personnel ;
• modification de vendor/magento/framework/App/View.php pour inclure du code distant ;
• valeur de skimmer dans core_config_data, chemin design/head/includes ;
• cookie gl_google_advisor_824808 et connexions vers les adresses de commande et contrôle publiées par Sansec.

Si l'un de ces indices est présent, isolez le serveur, préservez les journaux, traitez tous les secrets comme exposés et faites intervenir un prestataire de réponse à incident.

Pourquoi ce cas dépasse-t-il Magento ?

Il montre à quelle vitesse l'exploitation peut devancer le correctif : la première attaque confirmée précède de trois jours le bulletin d'Adobe, et une boutique à jour des correctifs a tout de même été touchée. La réponse pratique relève d'une discipline plus que d'une action unique : savoir ce que l'on exploite et où cela est exposé, disposer d'une procédure testée pour appliquer des correctifs d'urgence en quelques heures, garder un WAF comme mesure d'attente et être prêt à renouveler tous les secrets que la plateforme pouvait lire.

Pour les équipes qui relient des agents ou assistants d'IA à l'arrière-boutique d'un site marchand (consultation de commandes, support client, mise à jour du catalogue), la même logique s'applique aux identifiants de l'agent. Un agent doté d'un jeton d'API vers la boutique hérite du rayon d'action d'une boutique compromise, et la clé de chiffrement de la boutique protège aussi ce jeton. Ajoutez les identifiants des agents à votre liste de renouvellement et limitez leur portée au minimum.

Comment tester l'exposition de votre boutique ?

1. Version et correctif : relevez la version et l'état du correctif VULN-39341 sur chaque environnement.
2. Exposition : les routes /graphql et /paypal/transparent/response/ sont-elles accessibles sans authentification, et derrière quel WAF ?
3. Surveillance : recevez-vous des alertes sur les fichiers PHP nouveaux sous pub/media ?
4. Secrets : savez-vous renouveler la clé de chiffrement et les identifiants associés en quelques heures ?
5. Reprise : disposez-vous d'une sauvegarde saine pour reconstruire un serveur compromis ?

Le Red Team Agent Express de CleanIssue (1 900 €, 5 jours) couvre les agents IA et leurs accès, y compris ceux qui interrogent votre boutique ou ses données : voir l'offre. Un rendez-vous découverte gratuit de 30 minutes suffit pour voir si une requête anonyme peut atteindre les outils de votre boutique par un agent. Pour le cadre, voyez la page sécurité des agents IA.