La CISA classe la faille PolyShell d’Adobe Commerce comme exploitée, trois mois après le correctif

17 mars 2026. Sansec publie ses recherches sur PolyShell, un moyen de téléverser des fichiers via l’API REST de Magento sans s’authentifier, en les déguisant en images. 30 mars 2026. L’éditeur observe une vague d’attaques automatisée : les assaillants déposent des web shells puis injectent du JavaScript dans les pages des boutiques. 27 octobre 2026. La CISA inscrit la CVE-2026-48356 à son catalogue KEV, avec une échéance fédérale au 10 novembre 2026. Le point qui compte : Adobe a corrigé la faille le 14 juillet 2026, soit trois mois et demi avant que l’agence américaine ne la classe comme exploitée — et un correctif ne supprime pas ce qui a déjà été déposé.

Une faille connue depuis mars, corrigée depuis juillet

PolyShell n’est ni une zero-day ni une découverte récente. Sansec l’a documentée dès le 17 mars 2026, et l’a nommée ainsi parce que la charge malveillante — un fichier PHP dissimulé dans une image — se déguise en « coquille » anodine. La faille elle-même est une CWE-434, un Unrestricted Upload of File with Dangerous Type : l’API REST de Adobe Commerce et de Magento Open Source accepte un fichier dont le type est dangereux, sans exiger d’authentification préalable.

La notation reflète la gravité. NVD et le dossier CVE cotent la faille à 9,3 en CVSS v3.1, et le bulletin d’Adobe à 9,6 ; les deux vecteurs sont AV:N/AC:L/PR:N/UI:R/S:C. La seule divergence porte sur l’impact de disponibilité. Concrètement : aucun privilège requis, une interaction utilisateur (la victime doit visiter une URL piégée ou interagir avec une page compromise), et une portée modifiée qui explique le score élevé.

Adobe a publié le correctif le 14 juillet 2026 dans le bulletin APSB26-73, sous forme de correctifs isolés plutôt que de paquets Composer : chaque patch ne s’applique qu’au dernier niveau de correctif de sa ligne (2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 ou 2.4.4-p18). Une boutique qui traîne sur un niveau antérieur doit d’abord monter, puis appliquer le patch. C’est précisément ce mécanisme qui crée la traîne : trois mois après, une part non négligeable du parc tourne encore sur une version vulnérable.

Ce que le KEV change réellement

L’inscription au catalogue Known Exploited Vulnerabilities du 27 octobre 2026 n’ajoute aucune information technique nouvelle. Elle change la nature de l’instruction : la CISA affirme désormais qu’il existe une exploitation active en conditions réelles, et impose aux agences fédérales américaines une échéance de remédiation au 10 novembre 2026, conformément à la directive BOD 26-04.

Pour le reste du monde, c’est un signal d’alarme daté. La CISA n’ajoute une faille au KEV que lorsqu’elle juge qu’elle est ou a été exploitée ; son champ « ransomware » reste ici à « Unknown », ce qui signifie que l’agence ne confirme pas encore d’usage dans des campagnes de rançongiciel, sans l’exclure non plus. Adobe, de son côté, maintenait au 11 août 2026 qu’il n’avait « pas connaissance d’exploits en conditions réelles » — une ligne qui précède l’inscription au KEV et qu’il faudra surveiller.

Sansec documente pourtant l’exploitation depuis longtemps. Dès le 30 mars 2026, l’entreprise décrivait une attaque automatisée de grande ampleur : des assaillants déposaient des web shells puis injectaient du JavaScript dans les pages des boutiques pour voler des données de paiement — le même schéma Magecart que celui observé sur Convertr. Le 24 octobre 2026, Sansec a rattaché PolyShell à une campagne de longue haleine, active depuis juillet 2025, qui charge des scripts malveillants depuis les blocs de contenu des boutiques.

Le piège du « j’ai patché, c’est réglé »

La leçon la plus dure de cette affaire tient en une phrase : patcher ferme la porte, mais ne sort pas ce qui est déjà entré. Un correctif supprime la vulnérabilité ; il ne retire pas les fichiers déposés, les backdoors installées ni les comptes administrateur créés pendant les mois où la faille était ouverte.

C’est exactement le scénario que Sansec décrit. Les attaquants ont déposé un fichier nommé accesson.php dans de nouveaux sous-dossiers assets/images/, et ont stocké des fichiers inattendus — y compris des images contenant du PHP — sous pub/media/custom_options/. Le point décisif : le fichier reste sur disque même si le serveur web l’empêche de s’exécuter. Autrement dit, une boutique peut être « corrigée » et continuer d’héberger la charge dormante qui attend une configuration de serveur plus permissive.

Sansec recommande donc une séquence précise : d’abord bloquer l’accès web au dossier pub/media/custom_options/ (cela limite les dégâts sans stopper le téléversement), puis vérifier les blocs et pages CMS à la recherche de scripts injectés, passer en revue les comptes administrateur inconnus, et renouveler les mots de passe de la base, de l’administrateur et des intégrations d’API après nettoyage. Les domaines de la campagne de chargement de scripts (deepveindrilling[.]com, additionalver[.]com et consorts) servent d’indicateurs, pas de preuve : certains étaient en usage avant la divulgation de PolyShell.

Pourquoi le parc Magento reste vulnérable si longtemps

Magento et Adobe Commerce alimentent une part considérable du commerce en ligne, des enseignes indépendantes aux grandes marques. Or ce parc a une particularité structurelle : chaque boutique est un assemblage sur mesure d’extensions, de thèmes et de code de paiement modifié. Conséquence directe, une mise à jour n’est jamais un simple clic — c’est un projet qui touche le cœur du chiffre d’affaires, et que les marchands repoussent par peur de casser le checkout.

La mécanique du correctif de juillet aggrave le problème. Adobe a livré la correction sous forme de correctifs isolés, applicables uniquement au dernier niveau de chaque ligne de version, et non via Composer comme les mises à jour habituelles. Une boutique qui a deux niveaux de retard doit donc d’abord migrer, puis patcher — deux opérations que l’on confond trop souvent avec « on verra plus tard ». C’est exactement le terrain sur lequel les assaillants prospèrent : une faille corrigée mais toujours exploitable sur des milliers de boutiques qui n’ont pas encore bougé.

L’économie du Magecart explique la persistance. Le vol de cartes se revend en masse, et une seule boutique compromise peut produire des milliers de numéros en quelques jours. Pour l’attaquant, le retour sur investissement d’un scan automatisé à la recherche de PolyShell — Sansec liste plus de cinquante adresses IP ayant scanné la faille — est disproportionné par rapport au coût. Dès qu’une faille de téléversement non authentifiée est documentée, elle devient une commodité exploitée à l’échelle, longtemps après que l’éditeur a publié son correctif.

Ce qu’il faut faire, dans l’ordre

1. Confirmez que le correctif est réellement en place. Le bulletin APSB26-73 renvoie au Commerce Version Tool d’Adobe, qui liste les correctifs de sécurité installés et manquants. Ne vous fiez pas à la version affichée : un patch isolé peut être absent même sur une ligne à jour.

2. Montez votre ligne de version. Les correctifs de juillet ne s’appliquent qu’au dernier niveau de chaque ligne (2.4.8-p5, 2.4.7-p10, etc.). Une boutique sur un niveau antérieur doit d’abord migrer, puis patcher. Les versions corrigées portent le suffixe -2026-jul.

3. Chassez ce qui a été déposé avant le patch. Inspectez pub/media/custom_options/ à la recherche de fichiers inattendus, cherchez le fichier accesson.php et ses variantes, et scrutez les blocs CMS (cms_block, cms_page) pour du JavaScript injecté.

4. Coupez les accès résiduels. Revoyez les comptes administrateur, renouvelez les identifiants de la base de données et des intégrations d’API, et — pour les agences fédérales américaines — respectez l’échéance du 10 novembre 2026.

Verdict

Si vous exploitez une boutique Adobe Commerce ou Magento Open Source, traitez cette inscription au KEV comme un ordre de chasse, pas seulement de patch. Vérifiez que le correctif APSB26-73 (ou une version -2026-jul) est réellement appliqué, puis inspectez les dossiers de téléversement, les blocs CMS et les comptes administrateur pour tout ce qui a pu être déposé entre mars et votre patch. Si vous déléguez votre boutique à une agence ou à une marketplace, demandez-lui la preuve que le correctif de juillet est en place et qu’elle a contrôlé les fichiers déposés : un prestataire qui ne sait pas répondre à ces deux questions ne connaît pas sa propre plateforme. La CVE-2026-48356 ne sera pas la dernière faille Magento à passer au KEV ; la prochaine fois, ce sera encore le décalage entre le correctif et la chasse qui fera la différence.

Références

• CISA — Known Exploited Vulnerabilities, CVE-2026-48356 (27 octobre 2026)
• NVD — CVE-2026-48356 (Adobe Commerce)
• Adobe — bulletin de sécurité APSB26-73 (14 juillet 2026)
• Sansec — recherche PolyShell (17 mars 2026)
• Sansec — vague d’attaques de masse PolyShell (30 mars 2026)
• Sansec — chargeur de blocs CMS deepveindrilling.com (24 octobre 2026)
• Rescana — analyse CVE-2026-48356 (28 octobre 2026)