RCE dans Magento / Adobe Commerce - PolyShell
- Loïc Castel
- il y a 5 jours
- 6 min de lecture
PolyShell est une vulnérabilité critique de Magento / Adobe Commerce qui permet à un attaquant non authentifié d’uploader des fichiers exécutables via l’API REST, ouvrant la voie à du RCE, du vol de cartes bancaires et à la prise de contrôle complète de boutiques en ligne, alors qu’aucun correctif stable n’est encore publié pour les versions de production, au moment de l’écriture de ce blog post.
Découverte par Sansec, la vulnérabilité est déjà exploitée massivement depuis mi‑mars 2026, avec plus de la moitié des boutiques vulnérables qui seraient activement attaquées selon certains retours de terrain.
Cette vulnérabilité fait suite à SessionReapers, une vulnérabilité critique sur Magento également liée à la désérialisation.
Synthèse rapide
PolyShell exploite une faille dans la gestion des uploads de fichiers de l’API REST de Magento, permettant un upload arbitraire sans authentification.
Les attaquants déposent principalement un webshell PHP déguisé en image (polyglot GIF/PHP) dans le répertoire d’upload, qui devient exécutable selon la configuration Apache/Nginx et permet ensuite RCE ou XSS stockée.
Toutes les versions de Magento Open Source et Adobe Commerce jusqu’à 2.4.9‑alpha2 sont concernées ; seul un correctif dans la branche pré‑release 2.4.9 existe pour l’instant, sans patch isolé pour les versions stables.
Des campagnes actives combinent accès initial via PolyShell, webshell persistant et skimmers de cartes, certains utilisant WebRTC pour contourner les CSP, avec des taux de compromission annoncés autour de 56% des boutiques vulnérables.
Références
https://slcyber.io/research-center/why-nested-deserialization-is-still-harmful-magento-rce-cve-2025-54236/ (vulnérabilité récente affectant Adobe Commerce / Magento, SessionReapers)
Chronologie et contexte de PolyShell
Sansec a rendu publique la vulnérabilité PolyShell mi‑mars 2026, décrivant un défaut critique dans l’API REST de Magento et Adobe Commerce autorisant des uploads de fichiers exécutables sans authentification. Le nom « PolyShell » vient du fait que l’attaque repose sur des fichiers polyglottes qui se présentent comme des images tout en contenant du code exécutable, typiquement du PHP.
Peu après la divulgation, plusieurs sources ont signalé que des exploits circulaient déjà et que des campagnes de scans automatisés visaient en masse les boutiques Magento exposées.
Des rapports communautaires évoquent qu’environ 56,7% des boutiques vulnérables subiraient déjà des tentatives d’exploitation ou des compromissions, ce qui en fait une menace de premier plan pour l’écosystème Magento.
Périmètre et versions impactées
Selon Sansec et de multiples analyses, la faille d’upload non restreint touche l’ensemble des versions Magento Open Source et Adobe Commerce jusqu’à 2.4.9‑alpha2 incluse. Adobe a corrigé le code vulnérable uniquement dans la branche de pré‑release 2.4.9, dans le cadre du bulletin APSB25‑94, mais n’a pas publié de correctif rétro‑portable pour les versions de production actuellement déployées.
Le code vulnérable serait présent depuis les premières versions de Magento 2, ce qui signifie que quasiment toutes les boutiques n’ayant pas migré vers une pré‑release 2.4.9 restent exposées si elles respectent les conditions d’exploitabilité côté serveur web. Suivant la configuration d’Apache ou Nginx, l’impact varie d’un simple dépôt de fichiers malveillants jusqu’à l’exécution de code à distance ou l’XSS stockée conduisant à des prises de contrôle de comptes administrateur.
Détails techniques de la vulnérabilité
La vulnérabilité réside dans la manière dont Magento gère les options de produits de type « file » via son API REST.Lorsqu’un client ajoute au panier un produit avec une option fichier, l’API accepte un objet file_info contenant des métadonnées ainsi que les données du fichier encodées en base64, qui sont ensuite écrites dans pub/media/custom_options/quote/ sans contrôles suffisants sur le type et le contenu.
Les attaquants abusent de ce mécanisme en envoyant un fichier polyglotte, par exemple un GIF comportant un en‑tête valide (GIF89a) suivi de code PHP.Magento stocke alors ce fichier tel quel dans le répertoire d’upload ; sur de nombreux environnements, il peut être servi par le serveur web comme script s’il porte une extension .php ou s’il est nommé index.php, ce qui permet son exécution distante.
Le webshell PolyShell et charges malveillantes
Sansec décrit un webshell typique observé dans les attaques PolyShell : il est déposé sous forme de fichier polyglotte GIF/PHP, fréquemment nommé index.php dans le répertoire d’upload.Ce webshell vérifie un cookie d en le comparant à un hash MD5 codé en dur, puis exécute tout code arbitraire fourni via une charge base64 décodée et passée à eval(), offrant un contrôle complet sur l’instance compromise.
Le même shell expose également une fonctionnalité d’upload additionnelle, déclenchée par un paramètre $_POST["up"], permettant aux attaquants de déposer d’autres fichiers ou backdoors dans l’arborescence de la boutique.
Une fois en place, ce webshell sert de point d’ancrage pour des activités ultérieures : déploiement de skimmers JavaScript, modification des gabarits de paiement, exfiltration de bases de données ou pivot vers d’autres systèmes.
Chaîne d’attaque observée et campagnes en cours
Plusieurs analyses décrivent une chaîne d’attaque en plusieurs étapes : exploitation de PolyShell pour uploader un polyglot, installation d’un webshell persistant, puis injection de skimmers ou de modules de vol de données sur les pages de checkout.
Dans certaines campagnes récentes, les acteurs ont recours à un skimmer basé sur WebRTC capable de contourner des politiques CSP strictes pour intercepter les données de cartes bancaires en temps réel côté navigateur.
Les rapports évoquent un niveau d’activité très élevé depuis le 19 mars 2026, avec une automatisation poussée des scans et exploitations sur l’ensemble de la surface Magento exposée à Internet.Un billet largement relayé estime que plus de la moitié des boutiques vulnérables sont déjà visées, soulignant l’écart entre la disponibilité d’un correctif en pré‑release et la réalité des déploiements en production.
Impact pour les boutiques Magento / Adobe Commerce
L’impact immédiat est la possibilité pour un attaquant non authentifié d’obtenir un accès shell sur le serveur hébergeant la boutique, selon la configuration du serveur web. Cela permet non seulement de manipuler le code de l’application Magento, mais aussi d’accéder aux fichiers de configuration contenant des secrets, aux bases de données, voire au système sous‑jacent si les permissions le permettent.
Même lorsque l’exécution directe de scripts PHP est bloquée dans le répertoire d’upload, les fichiers malveillants restent présents sur disque et peuvent devenir exécutables lors de migrations, changements de configuration ou erreurs d’administration ultérieures.
En parallèle, la compromission des pages de paiement par des skimmers peut conduire au vol massif de données de cartes, avec un impact important en termes de fraude, d’amendes réglementaires et d’atteinte à la réputation.
Détection et indicateurs de compromission
Les boutiques doivent en priorité inspecter le répertoire pub/media/custom_options/ (et ses sous‑répertoires, notamment quote/) à la recherche de fichiers exécutables ou suspects, comme des .php ou des fichiers GIF contenant du code PHP en clair.La présence d’un fichier index.php ou d’un polyglot GIF/PHP à cet emplacement est un signal fort d’exploitation de PolyShell.
Noms de fichier observés, envoyés lors de l'exploitation :
index.php, json-shell.php, bypass.phtml, c.php, r.php, rce.php, static.php, test.php, blocked-json.php, bypass-async.php, urlencode-shell.php, xx_malicious_file.php, ato_poc.html, mikhail.htmlDes listes d’adresses IP impliquées dans des scans PolyShell ont également été partagées par Sansec et d’autres acteurs, utiles pour la corrélation dans les journaux d’accès HTTP :
Mesures de mitigation recommandées
En l’absence de correctif stable pour les versions de production, la réduction de la surface d’attaque passe d’abord par la configuration du serveur web :
Les opérateurs doivent restreindre strictement l’accès au répertoire pub/media/custom_options/ (idéalement en le rendant complètement inaccessibles depuis Internet) et s’assurer qu’aucune règle Apache ou Nginx ne permet l’exécution de fichiers PHP ou de scripts dans cet emplacement.
Nginx : Ajouter une règle "location ^~ /pub/media/custom_options/ { deny all; }" avant les blocs de traitement PHP.
Apache : Vérifier que le fichier .htaccess dans pub/media/ est actif et contient "RewriteRule ^custom_options/ - [F,L]". L’usage d’un WAF spécialisé pour bloquer les tentatives d’upload de fichiers polyglottes ou les patterns d’attaque connus est recommandé pour une protection en temps réel.
Un patch temporaire et non-officiel est disponible via le lien suivant : https://github.com/markshust/magento-polyshell-patch/
Recommandations opérationnelles pour les équipes sécurité
Les éditeurs et intégrateurs Magento devraient traiter PolyShell comme un incident de priorité zéro : inventaire exhaustif des boutiques exposées, audit de configuration et durcissement immédiat des serveurs web.
Dans l’attente d’un patch de production, il est conseillé d’envisager la migration vers la branche 2.4.9 corrigée dans des environnements de pré‑production, puis de planifier une mise à jour contrôlée avec tests fonctionnels.
Côté SOC / Blue Team, il est crucial de mettre en place une surveillance renforcée des logs HTTP sur les endpoints REST de gestion de panier et d’options fichiers, en corrélant avec les IoC publics (IP de scan, chemins d’upload, signatures de webshell).
Les équipes de réponse à incident (https://www.safercy.com/reponse-a-incident) devraient prévoir des playbooks spécifiques PolyShell : isolement rapide des instances compromises, suppression des webshells, rotation des secrets, vérification de l’intégrité applicative et notifications réglementaires en cas de fuite de données de paiement.
Conclusion
PolyShell combine une surface d’attaque extrêmement large (toutes les boutiques Magento 2 n’ayant pas migré vers une pré‑release corrigée), une exploitation trivialement automatisable et des impacts potentiellement dévastateurs pour les e‑commerçants.
Entre l’absence temporaire de correctif de production, l’usage de webshells polyglottes et la montée en puissance d'attaques visant cette vulnérabilité en priorité, cette vulnérabilité doit être priorisée au même niveau qu’un RCE critique sur un composant cœur de l’infrastructure e‑commerce.
