PolyShell : RCE exploitée dans Magento et Adobe Commerce (CVE-2026-48356)

En bref

• CVE-2026-48356, baptisée PolyShell par l'équipe de recherche Sansec qui l'a découverte, est un téléversement de fichiers sans restriction dans l'API REST de Magento et d'Adobe Commerce : un appelant non authentifié peut écrire un fichier exécutable sur le serveur via les routes d'articles du panier invité. La fiche CVE d'Adobe lui attribue un score CVSS v3.1 de 9,3 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N).
• Toutes les branches de production sont affectées : Adobe Commerce 2.4.4 à 2.4.9 et Magento Open Source 2.4.6 à 2.4.9 à leurs niveaux de correctifs antérieurs à juillet 2026, ainsi que Commerce B2B et Adobe Commerce Events. Les versions correctives de juillet 2026 (2.4.9-2026-jul, 2.4.8-2026-jul, etc.) corrigent les branches prises en charge.
• La faille est exploitée à grande échelle dans des attaques réelles. Sansec a enregistré des scans automatisés massifs à partir du 19 mars 2026, du PHP malveillant téléversé dans 82 % des boutiques surveillées au 14 avril, et estime que 471 des 953 boutiques de la campagne de chargeur qui a suivi ont été infectées via PolyShell. La CISA a ajouté CVE-2026-48356 à son catalogue Known Exploited Vulnerabilities le 27 octobre 2026, avec une échéance fédérale au 10 novembre 2026.
• Appliquez dès maintenant la version corrective de juillet 2026 correspondant à votre branche. Si vous ne pouvez pas corriger aujourd'hui, bloquez l'accès web à pub/media/custom_options/ et filtrez les routes de l'API du panier invité au niveau d'un WAF, puis recherchez les shells téléversés et la porte dérobée accesson.php avec les vérifications ci-dessous.

Suis-je concerné ?

Vous êtes concerné si vous exécutez Adobe Commerce, Magento Open Source, Adobe Commerce B2B ou Adobe Commerce Events dans l'une des versions du tableau ci-dessous, et si votre API REST, y compris les routes du panier invité, est accessible sur le réseau.

La fiche CVE d'Adobe et Sansec divergent sur la version 2.4.9 en disponibilité générale : la fiche indique que 2.4.9 est affectée jusqu'au correctif de juillet, tandis que Sansec affirme que la version 2.4.9 en disponibilité générale du 12 mai 2026 contient déjà le correctif.

Sansec ajoute que les versions de juillet portent le correctif sur les anciennes branches prises en charge. Vérifiez où se situe votre build avant de vous considérer à l'abri.

Vérifiez la version de l'instance en cours d'exécution, pas celle d'une nouvelle image :

# From the Magento root directory
php bin/magento --version

# From the composer lock file
grep -A1 '"name": "magento/product-community-edition"' composer.lock   # Open Source
grep -A1 '"name": "magento/product-enterprise-edition"' composer.lock   # Adobe Commerce

# In a container
docker exec <container> php bin/magento --version

Comment corriger la faille ?

Installez la version corrective de juillet 2026 (APSB26-73) de votre branche via votre procédure habituelle de mise à niveau Composer ou en ligne de commande, puis vérifiez que php bin/magento --version indique le niveau corrigé. Le bulletin Adobe constitue la liste de référence des versions corrigées. Sansec rattache les rétroportages de juillet 2026 à APSB26-73 et la version 2.4.9 en disponibilité générale au précédent correctif APSB25-94 de la branche de préversion 2.4.9.

Si vous ne pouvez pas corriger aujourd'hui, deux mesures réduisent le risque. Toutes deux sont adaptées du bulletin Sansec :

• Bloquez l'accès web au répertoire de téléversement. Pour nginx, ajoutez ce bloc dans la configuration du serveur avant tout bloc location \.php$, afin que le gestionnaire PHP ne puisse pas prendre la priorité :

location ~* ^/pub/media/custom_options/ {
    return 403;
}

Pour Apache, vérifiez que pub/media/custom_options/.htaccess existe et contient :

<IfModule mod_php.c>
    php_flag engine 0
</IfModule>
Deny from all

Sansec souligne que la plupart des boutiques utilisent la configuration de serveur web personnalisée de leur hébergeur plutôt que l'exemple fourni par Adobe. - Bloquez les routes de l'API du panier invité au niveau d'un WAF. C'est le seul contrôle qui arrête le téléversement lui-même, car le blocage des répertoires laisse le chemin d'écriture ouvert.

Limites : bloquer l'accès ne bloque pas les téléversements. Les attaquants peuvent toujours écrire des fichiers sur disque via l'API, et un changement de configuration, une migration ou un remplacement du serveur web peut ensuite les rendre exécutables. Même lorsque l'exécution PHP est bloquée dans le répertoire de téléversement, la variante XSS stockée de cette faille, dans laquelle le fichier est servi comme contenu, subsiste selon l'analyse des versions de Sansec.

Quelle est la cause racine ?

L'API REST de Magento écrit sur disque un fichier issu d'une requête d'article de panier sans valider l'option, son type ni l'extension du fichier. L'analyse technique de Sansec, publiée le 17 mars 2026, décrit le mécanisme : lorsqu'une option de produit est de type file, Magento traite un objet file_info intégré contenant les données du fichier 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.

Selon l'analyse de Sansec, trois contrôles manquent :

1. Aucune validation de l'identifiant d'option. L'identifiant soumis n'est jamais vérifié par rapport aux options réelles du produit.
2. Aucun contrôle du type d'option. La logique de téléversement se déclenche que le produit propose ou non une option de type fichier.
3. 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 (getimagesizefromstring), qu'un fichier polyglotte constituant à la fois une image valide et du PHP exécutable franchit sans difficulté.

Les points d'accès les plus dangereux sont les routes anonymes du panier invité, qui ne nécessitent aucun identifiant :

Les mutations GraphQL empruntent un autre chemin de code et ne sont pas vulnérables, selon Sansec. Adobe n'a publié ni diff officiel du correctif ni analyse de la correction pour CVE-2026-48356 ; sa logique exacte ne peut donc pas être citée ici. Le correctif a d'abord été livré dans la branche de préversion 2.4.9 (APSB25-94), puis dans la version 2.4.9 en disponibilité générale du 12 mai 2026 et dans les rétroportages de juillet 2026 pour chaque branche prise en charge.

Comment est-elle exploitée ?

Le chemin d'attaque, décrit dans l'analyse des payloads publiée par Sansec, conduit d'une seule requête non authentifiée à une porte dérobée persistante :

1. L'attaquant envoie une requête POST à /V1/guest-carts/:cartId/items avec un objet file_info dont le payload base64 est polyglotte : une image GIF ou PNG valide qui contient aussi du PHP exécutable, satisfaisant ainsi le contrôle d'en-tête d'image.
2. Le fichier est écrit sous pub/media/custom_options/quote/, souvent avec un nom comme index.php, éventuellement précédé de l'identifiant d'option, par exemple 780index.php.
3. Dans les configurations qui transmettent au gestionnaire PHP les fichiers .php du répertoire de téléversement ou de ses sous-répertoires, le fichier s'exécute sous l'identité de l'utilisateur du serveur web lorsqu'il est demandé. Sansec associe ce comportement à la configuration nginx d'exemple livrée avec Magento 2.0.0 à 2.2.x (via le nom index.php), à toute version de Magento derrière une configuration nginx personnalisée transmettant tous les .php à fastcgi, et à Apache sur les versions Magento antérieures à 2.3.5 sans php_flag engine 0.
4. Le payload le plus fréquent capturé par Sansec est un web shell polyglotte GIF89a nommé index.php : il vérifie le cookie d contre le hachage codé en dur a17028468cb2a870d460676d6d6da3ad63706778e3, puis exécute du PHP arbitraire via eval(base64_decode()) et comprend une fonction de téléversement déclenchée par $_POST["up"]. Une seconde variante utilise hash_equals() avec le MD5 codé en dur 4009d3fa8132195a2dab4dfa3affc8d2 et transmet les commandes directement à system().
5. Pour persister, les attaquants déploient une porte dérobée secondaire appelée accesson.php, placée dans <top-level directory>/assets/images/accesson.php sous chaque répertoire de premier niveau accessible en écriture. Sansec recense dix chemins de ce type sur une boutique, notamment var/assets/images/accesson.php, app/assets/images/accesson.php, vendor/assets/images/accesson.php et pub/assets/images/accesson.php. Elle affiche le marqueur 8194460 pour permettre à l'opérateur de repérer les shells actifs à grande échelle et fonctionne autrement comme le premier payload.
6. Enfin, les attaquants injectent un chargeur JavaScript obfusqué dans des pages ou blocs CMS, qui distribue d'autres payloads aux navigateurs des clients.

Les noms de fichiers PolyShell observés dans des attaques réelles comprennent 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 et xx_malicious_file.php. Des obfuscations Unicode comme \u0062\u0079\u0070\u0061\u0073\u0073.\u0070\u0068\u0070 (qui se décode en bypass.php) ont également été observées.

L'ampleur a été immédiate. La télémétrie de Sansec montre que 23 % des boutiques protégées avaient été ciblées au 23 mars 2026, puis 79,5 % au 30 mars. Du PHP malveillant avait été téléversé dans 56,7 % des boutiques au 24 mars et dans 82 % au 14 avril. Tout cela s'est produit avant l'existence du premier correctif en disponibilité générale.

Que peut faire un attaquant ?

L'impact dépend de la configuration du serveur web, et les deux cas sont préoccupants. Lorsque PHP s'exécute, l'attaquant lance du code sous l'identité de l'utilisateur du serveur web : web shells, contrôle complet de la boutique et possibilité de lire et de réécrire la base de données. Sansec a observé exactement cela dans des attaques réelles, avec des web shells déguisés en images PNG dans pub/media/custom_options/quote/, accompagnés d'un chargeur dans un bloc CMS. Lorsque l'exécution est bloquée, le fichier téléversé reste sur disque, où un futur changement de configuration peut l'exposer, et la variante XSS stockée peut à la place prendre le contrôle d'une session d'administrateur.

Note sur le score : La fiche CVE d'Adobe attribue à la faille un score CVSS v3.1 de 9,3 avec un changement de périmètre, et indique que son exploitation « pourrait entraîner l'exécution de code arbitraire dans le contexte de l'utilisateur courant, permettant potentiellement d'obtenir des accès élevés ou le contrôle du compte ou de la session de la victime ». Le vecteur UI:R de la fiche évalue les chemins qui nécessitent qu'une victime visite du contenu spécialement conçu ; le téléversement via le panier invité ne nécessite lui-même ni identifiants ni interaction utilisateur.

Les conditions nécessaires à l'attaque :

• Une API REST accessible sur une version affectée, y compris les routes anonymes du panier invité.
• Pour exécuter du code plutôt que simplement déposer un fichier, une configuration de serveur web qui exécute les fichiers PHP depuis le chemin de téléversement. Sansec a constaté que de nombreuses boutiques exposent les fichiers de ce répertoire.
• Rien d'autre : aucun compte, aucune authentification, aucune action utilisateur pour l'étape de téléversement.

Le correctif est-il vérifié ?

Non. Adobe n'a publié ni diff officiel ni analyse de la correction ; le correctif ne peut donc pas être vérifié à partir d'un diff. Les éléments publics sont les suivants : il a d'abord été intégré à la branche de préversion 2.4.9 sous APSB25-94 (14 octobre 2025, corrigé dans 2.4.9-alpha3), puis livré dans la version 2.4.9 en disponibilité générale le 12 mai 2026, et rétroporté vers chaque branche prise en charge dans les versions correctives de juillet 2026 (APSB26-73), selon le bulletin Sansec et la fiche CVE d'Adobe.

Une correction complète du comportement décrit par Sansec doit combler les trois lacunes : valider l'identifiant d'option soumis par rapport au produit, accepter file_info uniquement lorsque le produit déclare réellement une option de type fichier, et restreindre les noms de fichiers et extensions pouvant être écrits.

La télémétrie de Sansec a atteint 82 % de boutiques surveillées contenant des téléversements malveillants au 14 avril, avant la disponibilité générale du 12 mai et avant tout rétroportage pour les anciennes branches. L'inscription au catalogue KEV le 27 octobre montre que les installations non corrigées sont toujours attaquées.

Comment vérifier si j'ai été compromis ?

Ces vérifications et indicateurs sont adaptés du bulletin Sansec. Exécutez-les depuis le répertoire racine de Magento sur chaque boutique dont le niveau de version est affecté ou antérieur :

# Executable files in the custom options upload directory are a strong indicator.
find pub/media/custom_options/ -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)

# Stores that never offered file-type product options: any file other than
# .htaccess is suspicious. Legitimate customer file-option uploads land under
# pub/media/custom_options/quote/ and order/, so skip this on stores that use them.
find pub/media/custom_options/ -type f ! -name '.htaccess'

# The post-exploitation backdoor, placed under assets/images/ in top-level directories.
find . -name 'accesson.php' -type f

• Tout fichier .php, .phtml ou .phar sous pub/media/custom_options/ constitue un indicateur fort de compromission. Inspectez aussi les fichiers GIF et PNG : les shells polyglottes possèdent un en-tête GIF89a ou PNG avec du PHP à l'intérieur.
• Recherchez les domaines du chargeur de la campagne (tableau ci-dessous) dans les pages CMS et les blocs statiques (tables cms_block et cms_page). Les travaux antérieurs de Sansec sur la période PolyShell recensent aussi jslibrary[.]net et canevaslab[.]com.
• Auditez les comptes administrateurs : Sansec a documenté une boutique 2.4.7-p10 entièrement corrigée dont le seul signe de compromission était un compte administrateur illicite utilisé pour injecter le chargeur. Ce cas ne relevait pas de PolyShell, mais fait partie de la même campagne.
• Le bulletin Sansec recense plus de 50 adresses IP sources observées dans les scans PolyShell à partir de mars 2026, pour faciliter l'examen des journaux périmétriques.

Chronologie

• 2025-07 : début de la campagne du chargeur ; 953 boutiques, principalement sous Magento, sont infectées au cours de son déroulement (Sansec, publication d'octobre 2026).
• 2025-10-14 : la mise à jour APSB25-94 d'Adobe livre 2.4.9-alpha3, la préversion 2.4.9 dans laquelle Sansec situe la première intégration du correctif (APSB25-94, Sansec).
• 2026-03-16 : premières tentatives PolyShell observées à 12:00 UTC ; Sansec ajoute une protection Shield le jour même (Sansec).
• 2026-03-17 : Sansec publie son alerte publique et son analyse technique (Sansec).
• 2026-03-19 : début des scans automatisés massifs ; plus de 50 adresses IP de scanners suivent (Sansec).
• 2026-03-23 : 23 % des boutiques protégées par Sansec sont ciblées.
• 2026-03-24 : du PHP malveillant est téléversé dans 56,7 % des boutiques (Sansec).
• 2026-03-30 : 79,5 % des boutiques sont ciblées (Sansec).
• 2026-04-14 : du PHP malveillant est téléversé dans 82 % des boutiques (Sansec).
• 2026-05-12 : Adobe publie Magento 2.4.9 avec le correctif ; aucun rétroportage n'est encore disponible pour les anciennes branches prises en charge (Sansec).
• 2026-07-14 : publication de la fiche CVE d'Adobe et rétroportage du correctif vers les branches prises en charge dans les versions correctives de juillet 2026 (fiche CVE, APSB26-73).
• 2026-10-06 : enregistrement de deepveindrilling[.]com ; actif le 7 octobre ; présent dans les blocs CMS de 83 boutiques au 24 octobre (Sansec).
• 2026-10-27 : la CISA ajoute CVE-2026-48356 au catalogue Known Exploited Vulnerabilities ; échéance fédérale au 10 novembre 2026 (CISA KEV).
• 2026-10-28 : publication de cet article.

L'intervalle entre l'alerte publique et l'inscription au KEV est de 224 jours, et le correctif n'a atteint les anciennes branches prises en charge que 119 jours après l'alerte.

FAQ

PolyShell correspond-elle à la même CVE que la campagne du chargeur suivie par Sansec ?

Les deux sont liées, mais distinctes. CVE-2026-48356 (PolyShell) est la vulnérabilité de téléversement dans l'API REST. La campagne du chargeur suivie par Sansec (953 boutiques, cinq domaines depuis juillet 2025) est l'opération criminelle qui utilise PolyShell comme l'un de ses vecteurs d'entrée : Sansec estime que 471 boutiques ont subi une injection via PolyShell, et 102 autres via PolyShell ou la précédente faille SessionReaper (CVE-2025-54236). Au moins une boutique a été compromise via un compte administrateur illicite.

Mon serveur web bloque PHP dans le répertoire de téléversement. Suis-je à l'abri ?

Pas entièrement. Bloquer l'exécution arrête la variante d'exécution de code à distance, mais l'API continue d'écrire les fichiers de l'attaquant sur disque, la variante XSS stockée décrite par Sansec subsiste dans certaines configurations, et une future migration de serveur ou modification de configuration peut transformer ces fichiers en shells actifs. L'application du correctif constitue la remédiation complète ; les blocages du serveur web sont temporaires.

Pourquoi la CISA n'a-t-elle ajouté au KEV qu'en octobre une faille corrigée en juillet ?

Parce que l'exploitation se poursuit et que les installations non corrigées restent nombreuses. La faille a fait l'objet de scans massifs quelques jours après la divulgation de mars, le correctif n'a atteint les anciennes branches prises en charge qu'en juillet, et Sansec découvrait encore en octobre de nouveaux domaines de chargeurs dans les blocs CMS des boutiques. L'entrée KEV de la CISA, datée du 27 octobre 2026, fixe une échéance fédérale de remédiation au 10 novembre 2026.

Ai-je besoin d'une règle WAF si j'applique le correctif ?

Le correctif supprime la vulnérabilité ; une règle WAF devient donc facultative. Avant correction, Sansec précise que seule une règle WAF bloquant l'appel API vulnérable arrête les téléversements, car le blocage des répertoires laisse le chemin d'écriture ouvert. Son bulletin indique aussi qu'à sa dernière mise à jour, Cloudflare n'avait pas publié de règle WAF couvrant PolyShell. Ne comptez donc pas sur un WAF cloud pour bloquer PolyShell avant d'avoir confirmé qu'il dispose d'une règle adaptée.

Magento Open Source est-il affecté, ou seulement Adobe Commerce ?

Les deux. La fiche CVE d'Adobe recense des versions affectées d'Adobe Commerce, d'Adobe Commerce B2B, de Magento Open Source (branches 2.4.6 à 2.4.9) et d'Adobe Commerce Events, avec les versions correctives de juillet 2026 comme solution pour chacune.

Repérez les boutiques Adobe Commerce et Magento exposées avec Ostorlab

Lancez un scan web Ostorlab sur chaque boutique : il identifie la version et le niveau de correctifs Adobe Commerce ou Magento utilisés ainsi que l'exposition éventuelle des routes de téléversement du panier invité, pour vérifier que chacune exécute une version corrigée du tableau ci-dessus avant l'échéance KEV du 10 novembre.

Références

• Entrée CISA KEV pour CVE-2026-48356, ajoutée le 27 octobre 2026, échéance au 10 novembre 2026 : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consulté le 28 octobre 2026)
• Fiche CVE, CVSS v3.1 9,3, matrice des versions affectées et corrigées : https://cveawg.mitre.org/api/cve/CVE-2026-48356 (consulté le 28 octobre 2026)
• Bulletin de sécurité Adobe APSB26-73 (versions correctives de juillet 2026) : https://helpx.adobe.com/security/products/magento/apsb26-73.html
• Sansec, « PolyShell: unrestricted file upload in Magento and Adobe Commerce », 17 mars 2026, avec des mises à jour jusqu'en octobre 2026 (analyse technique, analyse des payloads, adresses IP des scanners, atténuation) : https://sansec.io/research/magento-polyshell (consulté le 28 octobre 2026)
• Sansec, « deepveindrilling.com: Magento CMS block loader hits 953 stores », octobre 2026 (attribution de la campagne : 471 via PolyShell, 102 via PolyShell ou SessionReaper, 83 boutiques avec le domaine du chargeur d'octobre) : https://sansec.io/research/magento-cms-block-loader-deepveindrilling (consulté le 28 octobre 2026)
• Sansec, « SessionReaper, unauthenticated RCE in Magento & Adobe Commerce (CVE-2025-54236) », pour la faille associée : https://sansec.io/research/sessionreaper
• The Hacker News, « Adobe Commerce PolyShell Attacks Breach Hundreds of Stores as Brotli Exploit Traffic Emerges », 28 octobre 2026 : https://thehackernews.com/2026/10/adobe-commerce-polyshell-attacks-breach.html
• The Hacker News, « Hackers Infect 953 Online Stores With Scanner-Evading JavaScript, Mostly on Magento », 26 octobre 2026 : https://thehackernews.com/2026/10/hackers-infect-953-online-stores-with.html
• The Hacker News, « Magento PolyShell Flaw Enables Unauthenticated Uploads, RCE and Account Takeover », 20 mars 2026, mis à jour le 23 mars avec les observations d'exploitation active : https://thehackernews.com/2026/03/magento-polyshell-flaw-enables.html