CVE-2026-48356 PolyShell : faille critique Magento, un upload de fichier permet l'exécution de code sur votre boutique

La CISA a ajouté le 27 octobre 2026 la vulnérabilité CVE-2026-48356 à son catalogue KEV (Known Exploited Vulnerabilities), confirmant son exploitation active sur des sites web e-commerce en production. Surnommée PolyShell par les chercheurs de Sansec, cette faille critique (CVSS 9.6, vecteur AV:N/AC:L/PR:N/UI:R/S:C) permet à un attaquant non authentifié d'uploader un script exécutable sur un serveur Magento ou Adobe Commerce via l'API REST. Le fichier, déguisé en image grâce à un en-tête GIF89a, contourne la validation et atterrit dans un répertoire accessible par le serveur web, ouvrant la porte à l'exécution de code arbitraire sur le processeur du serveur. Les versions touchées : Adobe Commerce jusqu'à 2.4.9 et Magento Open Source jusqu'à 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5 et 2.4.4-p18. Le correctif APSB26-73 est disponible depuis le 14 juillet 2026. Si vous êtes administrateur d'une boutique Magento hébergée sur un VPS Linux ou un serveur dédié, cet article détaille comment vérifier votre version, appliquer le patch et rechercher les fichiers suspects déjà déposés sur votre serveur.

Sources : bulletin de sécurité Adobe APSB26-73, alerte CISA du 27 octobre 2026.

CVE-2026-48356 : comprendre la faille PolyShell

La vulnérabilité se situe dans le traitement des fichiers joints aux options personnalisées d'un produit via l'API REST du framework PHP Magento. L'URL de l'endpoint concerné est POST /rest/default/V1/guest-carts/{cartId}/items, accessible sans authentification (panier invité). Un attaquant peut soumettre un objet file_info contenant un script encodé en base64, un type MIME et un nom de fichier vers cette URL.

Trois contrôles de sécurité manquaient dans le code d'upload :

• Pas de validation de l'option ID : Magento ne vérifiait pas que l'identifiant d'option soumis correspond réellement à un produit avec une option de type fichier configurée dans la config du catalogue.
• Pas de restriction de type : l'upload se déclenchait même si le produit n'avait aucune option de type fichier, ce qui permettait d'exploiter n'importe quelle boutique, même sans plugins ou extensions personnalisées.
• Pas de filtrage d'extension : les fichiers .php, .phtml et .phar n'étaient pas bloqués. La seule vérification était un appel à getimagesizefromstring(), qui contrôle l'en-tête du fichier mais pas son contenu réel.

Les attaquants exploitent cette faiblesse avec un fichier polyglotte : un script qui commence par un en-tête GIF89a valide (reconnu comme image GIF par la fonction de validation) mais qui contient du code PHP exécutable. Ce fichier est écrit sur le disque du serveur dans le répertoire pub/media/custom_options/quote/. Si le serveur web (Apache, Nginx) est configuré pour exécuter les fichiers PHP dans ce répertoire, l'attaquant obtient un shell distant sur votre serveur : il peut lire la config de Magento, accéder aux bases de données, et prendre le contrôle total de la machine.

Les mutations GraphQL de Magento utilisent un chemin de code différent et ne sont pas vulnérables à cette faille. Seuls les endpoints REST sont concernés.

Une exploitation active depuis mars 2026

L'exploitation de CVE-2026-48356 n'est pas théorique. Sansec a documenté les premières attaques dès le 19 mars 2026, avec un pic massif le 30 mars : 471 boutiques compromises en une heure par des campagnes automatisées. Dès le 23 mars, 23 % des sites web protégés par Sansec étaient ciblés. Les attaquants déposent un webshell (script PHP) via PolyShell, puis l'utilisent pour injecter du code malveillant dans les blocs CMS stockés dans la base de données MySQL de Magento. Les campagnes observées incluent des skimmers de cartes bancaires (vol de données de paiement en temps réel) et des backdoors persistantes capables de télécharger d'autres scripts depuis des serveurs distants.

Le backdoor le plus courant, nommé accesson.php, se déploie dans plusieurs répertoires du serveur pour survivre à un nettoyage partiel :

• var/assets/images/accesson.php
• pub/assets/images/accesson.php
• vendor/assets/images/accesson.php
• lib/assets/images/accesson.php
• app/assets/images/accesson.php

Ce script utilise un cookie d'authentification pour donner un accès shell à l'attaquant et exécuter du code arbitraire. D'autres noms de fichiers malveillants observés par Sansec incluent bypass.phtml, rce.php et json-shell.php. Les domaines externes contactés par les scripts injectés sont lanhd6549tdhse[.]top, jslibrary[.]net et canevaslab[.]com.

Adobe a publié le correctif dans le bulletin APSB26-73 le 14 juillet 2026, mais de nombreuses boutiques n'ont pas encore appliqué la mise à jour. L'ajout au catalogue KEV de la CISA le 27 octobre impose aux agences fédérales américaines un délai de correction au 10 novembre 2026, et sert de signal d'urgence pour tous les administrateurs de sites web Magento.

Versions affectées et versions corrigées

Le bulletin APSB26-73 couvre 14 CVE au total, dont CVE-2026-48356 est la plus critique. Voici les versions concernées et leurs correctifs. L'administrateur doit identifier sa branche de maintenance pour appliquer le bon patch :

Les correctifs de juillet 2026 sont distribués sous forme de patchs isolés (isolated patches), pas de nouvelles versions Composer classiques. L'administrateur doit les appliquer manuellement sur sa branche de maintenance. Si votre hébergeur fournit un service d'infogérance, vérifiez auprès de lui que le patch a bien été déployé.

Vérifier la version de votre Magento

Connectez-vous en SSH à votre serveur VPS ou serveur dédié hébergeant la boutique. L'administrateur doit disposer d'un accès shell avec les droits suffisants (utilisateur propriétaire du projet ou accès sudo). Depuis la racine du projet Magento, exécutez :

bin/magento --version

Cette commande affiche la version installée (par exemple Magento Open Source 2.4.7-p8). Attention : elle n'indique pas si un patch isolé a été appliqué par-dessus. Pour une vérification complète, interrogez Composer depuis votre shell :

composer show magento/product-community-edition 2>/dev/null
composer show magento/product-enterprise-edition 2>/dev/null

Si votre version correspond à l'une des branches vulnérables du tableau ci-dessus et que vous n'avez pas appliqué le patch isolé de juillet 2026, votre boutique est exposée. Vérifiez aussi la version de PHP installée sur votre serveur (php -v) : les patchs APSB26-73 requièrent PHP 8.1 ou supérieur selon la branche de Magento.

Appliquer le correctif APSB26-73

La procédure varie selon votre branche de maintenance. Consultez le bulletin APSB26-73 pour identifier le patch correspondant à votre version exacte. Voici la procédure générale à exécuter en tant qu'administrateur du serveur :

# Activer le mode maintenance (le site affiche une page d'indisponibilité)
bin/magento maintenance:enable

# Sauvegarder la base de données MySQL avant toute intervention
mysqldump -u magento_user -p magento_db > /root/magento_backup_$(date +%F).sql

Avant toute intervention sur votre serveur, sauvegardez vos données vers un serveur distant. Cette sauvegarde doit inclure les fichiers du projet, la base de données et les fichiers de config du serveur web. Appliquez ensuite le patch isolé depuis la racine du projet :

# Appliquer le patch (le nom exact dépend de votre version)
patch -p1 < APSB26-73_MDVA-XXXX_patch.patch

# Mettre à jour le schéma de la base de données et vider les caches
bin/magento setup:upgrade
bin/magento cache:flush

# Désactiver le mode maintenance
bin/magento maintenance:disable

Si votre installation utilise Adobe Commerce Events, mettez également à jour vers la version 1.21.0 via Composer. Les plugins et extensions tierces installés sur votre boutique ne sont pas affectés par ce patch, mais vérifiez leur compatibilité après la mise à jour. Contrôlez le statut du patch :

vendor/bin/patch-status

Testez ensuite le parcours d'achat complet (panier invité, checkout authentifié, produits avec options fichier) dans un environnement de pré-production avant de déployer sur le serveur de production. Vérifiez que les connexions à l'admin Magento et aux API REST fonctionnent correctement.

Auditer le répertoire pub/media

Appliquer le patch ne supprime pas les fichiers qu'un attaquant a pu déposer avant la correction. L'exploitation étant active depuis mars 2026, un audit complet du système de fichiers est indispensable. Connectez-vous en SSH avec un accès sudo à votre serveur et recherchez les fichiers dans le répertoire ciblé par PolyShell :

# Lister tous les fichiers dans le répertoire d'upload des options personnalisées
find pub/media/custom_options/ -type f ! -name '.htaccess' -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort

Ce répertoire ne devrait contenir que des fichiers légitimes uploadés par vos clients (images de personnalisation). Tout fichier avec une extension .php, .phtml ou .phar est un script suspect. Vérifiez aussi les fichiers dont l'extension semble anodine (.gif, .jpg) mais dont le contenu est un script PHP déguisé en image :

# Rechercher des fichiers polyglotte (image + PHP) dans pub/media
grep -rl '<?php\|<?=' pub/media/custom_options/ 2>/dev/null

Recherchez également le backdoor accesson.php et les autres scripts malveillants identifiés par Sansec :

# Rechercher les noms de fichiers connus comme malveillants
find . -type f \( -name 'accesson.php' -o -name 'bypass.phtml' -o -name 'rce.php' -o -name 'json-shell.php' \)
find pub/media/customer_address/ -type f ! -name '.htaccess'

Si vous trouvez des fichiers suspects, ne les supprimez pas immédiatement : conservez-les dans un répertoire de quarantaine hors de la racine web pour analyse. Vérifiez aussi les blocs CMS de votre base de données MySQL à la recherche de scripts JavaScript injectés par les attaquants :

mysql -u magento_user -p magento_db -e "
SELECT block_id, identifier, update_time FROM cms_block
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%'
OR content LIKE '%localStorage.getItem%' OR content LIKE '%jslibrary%';"

Analyser les logs du serveur web

Les logs d'accès de votre serveur web contiennent les traces des tentatives d'exploitation, y compris celles antérieures au patch. L'administrateur doit rechercher les requêtes POST suspectes vers les endpoints REST du panier invité. Sur un serveur Apache, les logs se trouvent généralement dans /var/log/apache2/access.log. Sur Nginx, dans /var/log/nginx/access.log :

# Rechercher les requêtes POST vers l'endpoint vulnérable dans les logs
grep -i 'POST.*guest-carts.*items' /var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/null | head -50

Chaque ligne suspecte contient l'adresse IP de l'attaquant, la date de la requête et la taille du payload. Si vous identifiez des adresses IP ayant envoyé des requêtes POST volumineuses (plus de 50 Ko) vers cet endpoint, bloquez-les dans votre firewall nftables :

# Bloquer une adresse IP suspecte avec nftables
sudo nft add element inet filter blacklist { 203.0.113.42 }

Vérifiez également les connexions SSH échouées dans vos logs : un attaquant qui a obtenu un shell via PolyShell peut tenter d'élever ses privilèges en testant des mots de passe sur d'autres comptes du serveur. Si votre hébergeur propose un accès aux logs via un panneau admin, consultez-les aussi pour vérifier les connexions récentes.

Durcir la configuration du serveur web

En complément du patch, bloquez l'exécution de scripts PHP dans les répertoires de médias. Cette configuration du serveur web limite l'impact de toute faille d'upload future sur vos sites web. Sous Apache, ajoutez dans votre .htaccess ou votre fichier de config du virtual host :

# Dans pub/media/.htaccess
<FilesMatch "\.(?:php|phtml|phar)$">
    Require all denied
</FilesMatch>

Sous Nginx, ajoutez une directive dans le bloc location correspondant. Si vous utilisez Nginx comme reverse proxy, ajoutez cette règle dans la config du virtual host qui sert Magento :

location ~* ^/media/.*\.(?:php|phtml|phar)$ {
    deny all;
    return 403;
}

Cette configuration empêche le serveur web d'exécuter des scripts PHP dans le répertoire de médias, même si un attaquant parvient à en déposer un. C'est une bonne pratique de durcissement de serveur dédié applicable à toute installation Magento. Vérifiez aussi que votre certificat SSL est valide et que toutes les URL de votre nom de domaine sont servies en HTTPS : vérifiez votre certificat TLS avec openssl.

Mesures complémentaires pour les administrateurs

CVE-2026-48356 rappelle que l'hébergement d'une boutique e-commerce exige une vigilance constante sur la sécurité du serveur, qu'il s'agisse d'un serveur virtuel (VPS) ou d'un serveur dédié bare metal. Voici les mesures à appliquer en parallèle du patch :

• Mises à jour automatiques du système : configurez les mises à jour de sécurité automatiques sur votre serveur Ubuntu ou Debian pour que les correctifs du système d'exploitation, de PHP, du serveur web et des bases de données soient appliqués sans intervention manuelle de l'administrateur.
• Sauvegardes régulières : une sauvegarde quotidienne de la base de données MySQL et des fichiers permet de restaurer la boutique en cas de compromission. Sauvegardez vers un serveur distant avec rsync pour isoler les copies de sauvegarde de l'attaquant.
• Firewall applicatif (WAF) : un firewall peut bloquer les requêtes suspectes vers les URL des endpoints REST vulnérables avant qu'elles n'atteignent le framework PHP. Configurez des règles spécifiques pour bloquer les uploads de fichiers non autorisés sur les endpoints guest-carts.
• Surveillance des connexions et du monitoring : mettez en place des alertes de monitoring sur la charge processeur et la RAM de votre serveur. Un pic inhabituel de consommation peut signaler l'exécution d'un script malveillant (cryptomineur, exfiltration de données).
• Audit des plugins et extensions : les plugins et extensions Magento tiers peuvent ajouter d'autres surfaces d'attaque. Désactivez les plugins inutilisés et mettez à jour ceux qui le sont. Vérifiez que les extensions n'exposent pas d'endpoints REST ou GraphQL supplémentaires non sécurisés.
• Restriction des accès admin : limitez l'accès au panneau admin de Magento par adresse IP dans la config de votre serveur web. Changez l'URL de l'admin (admin par défaut) pour une URL personnalisée et activez l'authentification à deux facteurs pour toutes les connexions admin.
• Conteneurisation : si votre Magento tourne dans Docker sur un serveur virtuel, reconstruisez vos images avec le patch appliqué et redéployez les conteneurs.

Chronologie de CVE-2026-48356

Questions fréquentes

Réponses aux questions courantes des administrateurs de serveurs hébergeant des boutiques Magento ou Adobe Commerce.

Conclusion

CVE-2026-48356 (PolyShell) est une faille critique qui permet à un attaquant non authentifié de déposer un webshell sur n'importe quelle boutique Magento ou Adobe Commerce non patchée, via une simple requête POST sur l'URL de l'API REST du panier invité. L'exploitation est active depuis mars 2026, avec des centaines de sites web compromis par des scripts de skimming et des backdoors, et la CISA l'a officiellement inscrite au catalogue KEV le 27 octobre. Le correctif APSB26-73 est disponible depuis juillet 2026. Si vous êtes administrateur d'une boutique Magento hébergée sur un VPS Linux ou un serveur dédié, vérifiez votre version avec bin/magento --version, appliquez le patch isolé correspondant à votre branche, auditez le répertoire pub/media/custom_options/ à la recherche de scripts déposés avant la correction, et renforcez la sécurité de votre serveur pour limiter l'impact des prochaines vulnérabilités.