La CISA classe PolyShell comme exploitée pendant que la campagne Magento touche des centaines de boutiques

Une vulnérabilité qu'Adobe a corrigée en juillet provoque encore des intrusions en novembre. Le 27 octobre, la Cybersecurity and Infrastructure Security Agency américaine a ajouté CVE-2026-48356 à son catalogue des vulnérabilités exploitées connues et a donné aux agences fédérales jusqu'au 10 novembre pour la corriger. La faille, que la société de sécurité Sansec appelle PolyShell, est un téléversement de fichier non authentifié dans Adobe Commerce et Magento qui peut mener à une exécution de code à distance. Le NVD la note 9,3 sur 10.

À lire aussi: Le zero-day « StyleSmuggler » d'Adobe Commerce a frappé des boutiques trois jours avant le correctif · Le Patch Tuesday d'octobre 2026 de Microsoft établit un record avec 1 407 correctifs.

L'inscription au KEV est la reconnaissance officielle d'une campagne en cours depuis des mois. Sansec affirme que des attaquants ont utilisé la faille pour déposer un loader malveillant sur 953 boutiques en ligne, en l'injectant via un bloc CMS de Magento. L'entreprise a averti pour la première fois en mars, a vu le balayage de masse commencer en quelques jours et a suivi la campagne à travers le correctif d'Adobe et son rétroportage de juillet. Les boutiques qui n'ont pas mis à jour sont celles qui restent à risque.

The Hacker News rapporte que le loader est conçu pour récupérer et exécuter une charge utile contrôlée par l'attaquant, mais qu'aucun logiciel malveillant de l'étape suivante n'a été récupéré. Cet écart compte. Il signifie que l'objectif de la campagne n'est pas connu publiquement. Il peut s'agir d'un skimmer de paiement, d'un schéma de redirection, d'un collecteur d'identifiants ou d'une couche de préparation pour autre chose. L'activité est estimée en cours depuis au moins juillet 2025.

La faille : un champ de téléversement qui fait confiance au client

PolyShell réside dans l'API REST de Magento. Quand un produit propose une option personnalisée de type fichier, l'API accepte un objet fichier intégré avec des données encodées en base64, un type MIME et un nom de fichier, puis écrit le fichier dans pub/media/custom_options/quote/ sur le serveur. Sansec a trouvé trois contrôles manquants :

• Aucune validation de l'identifiant d'option. L'identifiant d'option soumis n'est jamais vérifié par rapport aux options réelles du produit.
• Aucun filtrage par type d'option. La logique de téléversement s'exécute que le produit ait ou non une option de type fichier.
• Aucune restriction d'extension. Les extensions comme .php, .phtml et .phar ne sont pas bloquées.

La seule validation est un contrôle d'en-tête d'image via getimagesizefromstring, qu'un fichier polyglotte peut franchir tout en contenant du PHP exécutable. Les points d'entrée les plus dangereux sont les routes du panier invité anonyme, POST /V1/guest-carts/:cartId/items et PUT /V1/guest-carts/:cartId/items/:itemId, qui ne demandent aucune authentification. Les mutations GraphQL passent par un autre chemin de code et ne sont pas vulnérables.

La capacité du fichier téléversé à s'exécuter dépend du serveur web. Des configurations nginx d'origine, dans certaines versions, transmettent les fichiers .php à FastCGI, et des installations Apache sans php_flag engine 0 peuvent faire de même. Sansec indique que de nombreuses boutiques utilisent des configurations personnalisées de leur hébergeur, ce qui explique la variabilité de l'impact. Même quand l'exécution est bloquée, le fichier reste sur le disque. Un futur changement de configuration, une migration ou un changement de serveur peut le rendre dangereux à nouveau.

La campagne : 953 boutiques et une porte dérobée persistante

La chronologie de Sansec commence le 16 mars 2026, quand l'entreprise ajoute une protection PolyShell à son produit Shield. Elle publie un avertissement le lendemain. Les premières attaques apparaissent le 19 mars, et le balayage automatisé de masse commence le 23 mars. Au 24 mars, Sansec indique que 56,7 % de toutes les boutiques qu'elle protège avaient reçu du code PHP malveillant. Au 30 mars, 79,5 % avaient été ciblées. Au 14 avril, le chiffre atteignait 82 %.

Les attaquants ne se sont pas arrêtés au téléversement initial. Sansec a trouvé une porte dérobée secondaire appelée accesson.php, dispersée dans plusieurs répertoires de boutiques compromises, dont var/assets/images/, app/assets/images/, vendor/assets/images/ et pub/assets/images/. Ces copies constituent une stratégie de persistance. Nettoyer un répertoire ne supprime pas les autres. La porte dérobée signale sa présence en affichant un nombre fixe, accepte des commandes via une évaluation PHP authentifiée par cookie et peut téléverser d'autres fichiers.

La dernière couche est du JavaScript. Sansec a trouvé un loader obfusqué injecté dans des pages et des blocs statiques du CMS. Le loader stocke une charge utile dans le localStorage du navigateur, ce qui lui permet de survivre au rechargement des pages même si la source externe disparaît, et récupère une charge utile fraîche depuis des domaines dont lanhd6549tdhse[.]top. Cette conception complique le nettoyage : supprimer l'injection côté serveur empêche de nouveaux visiteurs d'être infectés, mais ne nettoie pas les navigateurs qui ont déjà mis la charge utile en cache.

PolyShell permet aux attaquants de téléverser des fichiers exécutables sur n'importe quelle boutique Magento ou Adobe Commerce via l'API REST.

Pourquoi un correctif de juillet n'a pas suffi

Adobe a corrigé la faille sous-jacente dans Magento 2.4.9, publié le 12 mai 2026, et a rétroporté le correctif vers les branches prises en charge le 14 juillet via APSB26-73. C'est la bonne séquence. C'est aussi le moment où la correction ralentit généralement.

Les boutiques qui ont appliqué la mise à jour ne sont plus vulnérables au téléversement. Celles qui ne l'ont pas fait le sont toujours. Les installations Magento et Adobe Commerce sont souvent personnalisées par des agences et des hébergeurs, ce qui rend les montées de version plus lentes et plus risquées qu'une mise à jour logicielle de routine. Un marchand peut retarder un correctif parce qu'un module personnalisé dépend de l'ancien code, parce que la fenêtre de mise à jour est étroite avant une période de soldes ou parce que personne n'a la tâche en charge. L'inscription au KEV vise à retirer cette latitude aux agences fédérales. Elle ne lie pas les marchands privés.

Le résultat est une longue traîne de boutiques vulnérables que les attaquants peuvent balayer automatiquement. Les données de balayage de masse de Sansec montrent à quelle vitesse cette traîne est trouvée. Les 953 boutiques de la campagne de loader en sont la partie visible. Le nombre de boutiques sondées sans être compromises est plus élevé, et celui des boutiques encore non corrigées l'est davantage.

Ce que les exploitants de boutique doivent faire

La première étape est de confirmer la version de Magento ou d'Adobe Commerce. Les boutiques en 2.4.9 ou sur une branche ayant reçu le rétroportage APSB26-73 disposent du correctif. Celles qui restent sur des versions plus anciennes non.

La deuxième est de bloquer le chemin de téléversement au niveau du serveur web. La règle nginx de Sansec refuse tout accès à pub/media/custom_options/ avant tout bloc de localisation .php. L'équivalent Apache est un fichier .htaccess dans ce répertoire avec php_flag engine 0 et Deny from all. Bloquer l'exécution n'arrête pas le téléversement, mais supprime le chemin le plus simple vers l'exécution de code pendant que le correctif est appliqué.

La troisième est de rechercher une compromission. Sansec recommande de chercher les fichiers .php, .phtml ou .phar dans pub/media/custom_options/ et accesson.php n'importe où dans la racine du document. Les propriétaires de boutique devraient aussi chercher dans les pages et blocs statiques du CMS des références aux domaines du skimmer et examiner les journaux du serveur pour des requêtes vers les points d'entrée du panier invité venant de sources inattendues.

La quatrième est de renouveler les identifiants. Une porte dérobée capable de téléverser des fichiers et d'exécuter du code a peut-être servi à lire des fichiers de configuration, des clés de paiement ou des sessions administrateur. Supprimer le fichier n'équivaut pas à expulser l'attaquant.

À surveiller

L'échéance KEV du 10 novembre produira un chiffre de conformité aux correctifs pour les agences fédérales. Elle n'en produira pas pour le commerce de détail. Le signal plus utile est de savoir si Sansec et d'autres intervenants signalent de nouvelles infections par le loader après l'échéance. Si la campagne continue au même rythme, le problème est la base installée. Une faille facile à exploiter et lente à corriger reste une cible même après la publication d'un correctif par l'éditeur.

Adobe n'a pas publié d'estimation du nombre de boutiques encore non corrigées. Les pourcentages de Sansec décrivent sa propre base de clients protégés, pas l'ensemble du marché. Cela limite la portée des généralisations, sans changer la direction. Une faille facile à exploiter, automatisée pour le balayage et lente à corriger est une cible durable, même après la publication d'un correctif par l'éditeur.

Mises en garde

• 953 est un décompte des boutiques où le loader a été trouvé. Ce n'est pas un nombre confirmé de boutiques dont les données clients ont été volées.
• Aucun logiciel malveillant de l'étape suivante n'a été récupéré. L'objectif, la charge utile et l'attribution de la campagne ne sont pas confirmés.
• Les pourcentages portent sur les boutiques protégées par Sansec. Ce ne sont pas des parts de toutes les boutiques Magento ou Adobe Commerce.
• L'échéance fédérale concerne les agences fédérales américaines. Les marchands privés n'ont aucune obligation légale équivalente.
• Adobe a corrigé la faille en mai et rétroporté le correctif en juillet. Les boutiques non corrigées restent vulnérables ; les boutiques corrigées non.
• Le statut du WAF de Cloudflare a pu changer. Sansec notait que Cloudflare n'avait pas publié de règle spécifique à PolyShell au moment de son analyse ; l'entreprise a bien livré une règle d'urgence pour la faille Brotli distincte.
• La chronologie est celle de Sansec. Adobe et la CISA n'ont pas publié d'historique complet de la campagne.

L'inscription au KEV transforme une vulnérabilité vieille de plusieurs mois en échéance. Pour les boutiques qui font encore tourner un Magento non corrigé, le balayage n'a jamais cessé.

Couverture : le siège mondial d'Adobe à San Jose, en Californie. Photographie de Coolcaesar, CC BY-SA 4.0, via Wikimedia Commons, recadrée en 16:9.