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

Publié le avril 2, 2026 · Dernière mise à jour avril 3, 2026 · par ALGERIATECH Editorial

⚡ Points Clés

Sansec a observé des attaques PolyShell sur 56,7 % de toutes les boutiques Magento vulnérables en quelques jours seulement après la divulgation, l'exploitation massive ayant débuté le 19 mars 2026 — et aucun correctif officiel n'existait pour les versions de production actuelles de Magento ou Adobe Commerce.

En résumé : Les entreprises e-commerce algériennes utilisant Magento ou Adobe Commerce devraient vérifier immédiatement leur niveau de correctif par rapport à APSB25-94 et bloquer les uploads de fichiers PHP au niveau du serveur web. Celles qui ne peuvent pas appliquer les correctifs devraient désactiver les uploads de fichiers non authentifiés via l'API REST comme mesure intérimaire. Le taux d'exploitation de 56,7 % signifie qu'un retard d'action aboutira presque certainement à une compromission.

Lire l’analyse complète ↓

🧭 Radar de Décision (Perspective Algérienne)

Pertinence pour l’Algérie
Moyenne
▾

Le secteur e-commerce algérien a connu une croissance de 92 % par an depuis 2020, avec un nombre croissant de boutiques basées sur Magento. Les entreprises traitant des paiements en ligne sont directement exposées si elles utilisent des installations non corrigées.

Infrastructure prête ?
Partielle
▾

Les plateformes e-commerce algériennes existent, mais la plupart manquent de surveillance de sécurité dédiée ou de déploiements WAF capables de détecter ou bloquer les tentatives d’exploitation PolyShell.

Compétences disponibles ?
Limitées
▾

L’expertise en sécurité spécifique à Magento est rare en Algérie. La plupart des boutiques s’appuient sur des développeurs externes qui ne surveillent pas forcément les divulgations de vulnérabilités ou n’appliquent pas les correctifs d’urgence rapidement.

Calendrier d’action
Immédiat
▾

L’exploitation de PolyShell est active en ce moment, avec 56,7 % des boutiques vulnérables déjà compromises. Tout opérateur Magento algérien doit appliquer les correctifs ou les atténuations aujourd’hui.

Parties prenantes clés
Opérateurs e-commerce, processeurs de paiement, développeurs web, consultants en cybersécurité

Type de décision
Tactique
▾

Cet article fournit des atténuations spécifiques, immédiatement actionnables pour les administrateurs Magento face à une campagne d’exploitation massive active.

Synthèse : Les entreprises e-commerce algériennes utilisant Magento ou Adobe Commerce devraient vérifier immédiatement leur niveau de correctif par rapport à APSB25-94 et bloquer les uploads de fichiers PHP au niveau du serveur web. Celles qui ne peuvent pas appliquer les correctifs devraient désactiver les uploads de fichiers non authentifiés via l’API REST comme mesure intérimaire. Le taux d’exploitation de 56,7 % signifie qu’un retard d’action aboutira presque certainement à une compromission.

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.

Suivez AlgeriaTech sur LinkedIn pour des analyses tech professionnelles Suivre sur LinkedIn

Suivez @AlgeriaTechNews sur X pour des analyses tech quotidiennes Suivre sur X

Questions Fréquemment Posées

Qu’est-ce que PolyShell et pourquoi est-ce si dangereux ?

PolyShell est une vulnérabilité zero-day critique dans Magento et Adobe Commerce qui permet à des attaquants non authentifiés d’uploader des fichiers polyglotte — des fichiers simultanément valides comme images et comme scripts PHP exécutables — via l’API REST. Elle affecte toutes les versions de production et ne nécessite aucune interaction utilisateur ni authentification, la rendant trivialement exploitable à grande échelle. En deux semaines après la divulgation, 56,7 % de toutes les boutiques vulnérables avaient été compromises.

Comment savoir si ma boutique Magento a été compromise par PolyShell ?

Recherchez dans votre installation Magento les fichiers nommés accesson.php ou tout fichier PHP récemment créé dans le répertoire pub/media/custom_options/quote/. Vérifiez les fichiers JavaScript du frontend pour du code obfusqué référençant des domaines externes, en particulier lanhd6549tdhse.top. Si vous trouvez l’un de ces indicateurs, considérez la compromission complète, incluant le vol potentiel de données de cartes de paiement.

Que devraient faire les opérateurs e-commerce algériens maintenant ?

Appliquez immédiatement les correctifs de sécurité APSB25-94 d’Adobe. Si la mise à jour n’est pas possible dans les 24 heures, configurez votre serveur web (Nginx ou Apache) pour bloquer les uploads de fichiers .php, .phtml et .phar vers le répertoire des options personnalisées. Déployez une règle WAF de Cloudflare ou Sucuri pour filtrer les charges PolyShell, et mettez en place une surveillance de l’intégrité des fichiers sur tous les répertoires d’upload média.