PolyShell, zero-day Magento : 57 % des boutiques vulnérables touchées en quelques jours

Un fichier polyglotte se présente à l’API REST

Le 17 mars 2026, la société de sécurité e-commerce Sansec a divulgué publiquement une vulnérabilité qu’elle a nommée PolyShell — une faille d’upload de fichier non restreint sans authentification affectant toutes les versions de production de Magento Open Source et Adobe Commerce. En deux jours, l’exploitation massive automatisée a commencé. En deux semaines, plus de la moitié de toutes les boutiques vulnérables avaient été touchées.

La vulnérabilité est élégante dans sa simplicité. L’API REST de Magento accepte les uploads de fichiers dans le cadre des options personnalisées d’articles du panier. Quand une option produit est définie sur le type « file », l’API traite un objet file_info intégré contenant des données fichier encodées en base64, un type MIME et un nom de fichier. Le fichier uploadé est écrit dans le répertoire pub/media/custom_options/quote/ du serveur.

La faille critique : aucune restriction d’extension de fichier. Les extensions comme .php, .phtml et .phar ne sont pas bloquées. La seule validation est un contrôle d’en-tête image via getimagesizefromstring(), qui est trivialement contourné à l’aide d’un fichier polyglotte — un fichier qui est simultanément valide en tant qu’image et script PHP.

L’exploit le plus simple préfixe GIF89a (un en-tête GIF valide) à une charge PHP. Tant que le fichier commence par GIF89a et contient quelques données, getimagesizefromstring() le considère comme une image valide. L’interpréteur PHP ignore l’en-tête image et exécute le code.

Le résultat : exécution de code à distance sans authentification sur toute boutique Magento avec la configuration par défaut.

La chronologie de l’exploitation

La vitesse de l’exploitation massive distingue PolyShell des zero-days typiques d’applications web.

16 mars, 12:00 UTC — Première activité de sondage détectée par Sansec. Les attaquants commencent la reconnaissance des endpoints de l’API REST Magento.

17 mars — Sansec publie sa divulgation de recherche nommant la vulnérabilité « PolyShell ».

19 mars — Le scan massif automatisé démarre avec pas moins de 50 adresses IP participant à la vague de scan initiale.

19-29 mars — Campagne d’exploitation soutenue. Les attaquants déploient des portes dérobées, injectent du JavaScript malveillant et établissent un accès persistant sur des milliers de boutiques.

30 mars — Une vague d’attaques massives frappe des centaines de boutiques en une seule heure, injectant des chargeurs JavaScript depuis le domaine malveillant lanhd6549tdhse.top.

Au moment où Sansec a mesuré l’impact, les attaques PolyShell avaient touché 56,7 % de toutes les boutiques vulnérables — un taux d’exploitation qui éclipse les campagnes de vulnérabilités web typiques.

L’étendue de l’exposition

PolyShell affecte environ 112 000 à 130 000 boutiques Magento actives traitant un volume combiné de 173 milliards de dollars de valeur brute de marchandises annuelle. Cela inclut les installations Magento Open Source (communauté) et Adobe Commerce (entreprise).

Adobe a corrigé la faille dans la branche pré-release 2.4.9 et a ensuite publié des correctifs de sécurité pour les versions de production (2.4.4-p16 à 2.4.8-p3) dans le cadre du bulletin de sécurité APSB25-94. Cependant, la grande majorité des boutiques n’avaient pas appliqué ces correctifs au moment où l’exploitation massive a commencé — et la période de divulgation initiale a laissé toutes les boutiques de production exposées.

Ce décalage de mise à jour est la caractéristique déterminante de la crise PolyShell. Le taux d’exploitation de 56,7 % reflète que la plupart des boutiques n’avaient pas appliqué les correctifs même après leur disponibilité, soulignant l’écart persistant entre la disponibilité des correctifs et leur adoption dans l’écosystème Magento.

Post-exploitation : portes dérobées et injection JavaScript

Obtenir l’exécution initiale de code par PolyShell n’est que la première étape. Sansec a documenté un plan de post-exploitation cohérent :

Étape 1 : Déployer la porte dérobée accesson.php. Après avoir obtenu l’exécution de code à distance, les attaquants pulvérisent une porte dérobée secondaire nommée accesson.php dans plusieurs répertoires pour maximiser la persistance. Même si le fichier polyglotte original est découvert et supprimé, la porte dérobée accesson fournit un accès continu.

Étape 2 : Injecter du JavaScript obfusqué. Des chargeurs JavaScript malveillants sont injectés dans le frontend de la boutique, chargeant des malwares externes depuis des domaines contrôlés par les attaquants. Ce JavaScript capture les données de cartes de paiement saisies par les clients lors du checkout — le schéma classique de skimming Magecart, désormais délivré par un point d’entrée zero-day. Dans certains cas, les attaquants ont déployé un nouveau skimmer basé sur WebRTC capable de contourner les protections Content Security Policy (CSP), représentant une évolution dans la boîte à outils de skimming.

Étape 3 : Établir la prise de contrôle des comptes clients. Au-delà du skimming, la vulnérabilité permet le cross-site scripting (XSS) stocké qui peut être utilisé pour la prise de contrôle des comptes clients, accédant aux historiques de commandes, aux moyens de paiement enregistrés et aux données personnelles.

La post-exploitation multi-étapes signifie que le nettoyage d’une compromission PolyShell nécessite plus que la correction de la faille d’upload. Chaque répertoire doit être scanné pour les variantes d’accesson.php, tous les fichiers JavaScript doivent être audités pour les chargeurs injectés, et les sessions clients doivent être invalidées.

Atténuations immédiates

Bien qu’Adobe ait publié des correctifs de production, le faible taux d’adoption signifie que la plupart des boutiques restent non corrigées. Les administrateurs Magento qui n’ont pas encore appliqué les mises à jour APSB25-94 doivent mettre en œuvre des défenses manuelles immédiatement :

Bloquer les extensions dangereuses au niveau du serveur web. Configurez Nginx ou Apache pour rejeter les requêtes qui uploadent des fichiers avec les extensions .php, .phtml, .phar ou .shtml vers le répertoire des options personnalisées. C’est l’atténuation immédiate la plus efficace.

Restreindre l’accès à l’API REST. Si le checkout invité via l’API n’est pas requis, désactivez l’accès non authentifié au endpoint des options personnalisées d’articles du panier. Cela brise la chaîne d’attaque au point d’entrée.

Déployer une règle WAF. Les principaux fournisseurs de WAF, dont Cloudflare, Akamai et Sucuri, ont publié des règles pour détecter les charges PolyShell. La protection WAF ne remplace pas la mise à jour mais réduit l’exposition aux scans automatisés.

Surveiller le répertoire custom_options. Mettez en place une surveillance de l’intégrité des fichiers sur pub/media/custom_options/quote/ pour alerter sur tout nouveau fichier PHP. Les uploads légitimes vers ce répertoire ne devraient contenir que des fichiers image.

Scanner accesson.php. Recherchez dans toute l’installation Magento la présence d’accesson.php ou de tout fichier PHP récemment créé en dehors des répertoires attendus. La présence de ce fichier confirme une compromission active.

Auditer le JavaScript pour les chargeurs injectés. Vérifiez tous les blocs CMS, fichiers statiques et fichiers de template pour du JavaScript obfusqué référençant des domaines externes.

Pourquoi PolyShell dépasse le cadre de Magento

PolyShell est une étude de cas sur le risque systémique des plateformes e-commerce monolithiques. La vulnérabilité existe parce que la validation d’upload de fichier de Magento fait confiance au type de contenu plutôt qu’à l’extension de fichier — un choix de conception qui privilégie la commodité à la sécurité.

Pour l’écosystème e-commerce élargi, PolyShell soulève trois questions inconfortables :

Combien d’autres plateformes présentent des lacunes de validation similaires ? Si l’API REST de Magento a raté le blocage des extensions sur les uploads de fichiers, les plateformes concurrentes devraient auditer leurs propres pipelines d’upload immédiatement.

Que se passe-t-il quand le délai de correction dépasse la fenêtre d’exploitation ? Adobe connaissait le correctif en pré-release mais n’a pas livré de correctif de production à temps. L’écosystème Magento absorbe le coût de ce décalage.

Les boutiques e-commerce peuvent-elles rester sécurisées sans ressources de sécurité dédiées ? Le taux d’exploitation de 56,7 % suggère que la plupart des boutiques Magento manquent de capacité de surveillance et de réponse pour détecter et atténuer les attaques zero-day. Le déficit de sécurité des petits commerçants est un problème structurel que les fournisseurs de plateformes n’ont pas résolu.

Questions Fréquemment Posées

Sources et lectures complémentaires

• PolyShell: Unrestricted File Upload in Magento and Adobe Commerce — Sansec
• Magento PolyShell Flaw Enables Unauthenticated Uploads, RCE and Account Takeover — The Hacker News
• PolyShell Attacks Target 56% of All Vulnerable Magento Stores — Bleeping Computer
• PolyShell Flaw Exposes Magento and Adobe Commerce to File Upload Attacks — Security Affairs
• PolyShell Alert: Critical Magento REST API Vulnerability Faces Massive Global Exploitation — Security Online
• Magento PolyShell — Unauthenticated File Upload to RCE (APSB25-94) — Searchlight Cyber