Sécurité

Faille PolyShell Magento : ce que vous devez faire maintenant

PolyShell (APSB25-94) permet à n'importe qui d'uploader et d'exécuter du code sur votre boutique Magento sans authentification. Comment détecter une compromission et appliquer le patch.

5 min de lecture Par L'équipe Vesora

Le 17 mars 2026, la société Sansec a divulgué publiquement PolyShell — une faille critique dans Magento Open Source et Adobe Commerce permettant à n’importe qui, sans compte ni authentification, d’uploader et d’exécuter du code arbitraire sur votre serveur.

Trois jours après la divulgation, l’exploitation de masse avait déjà démarré. Au 14 avril 2026, 82 % des boutiques Magento vulnérables avaient reçu des uploads malveillants. Aucun patch officiel n’est disponible pour les versions de production stables à ce jour.

Voici ce que vous devez faire, maintenant.

Ce que fait PolyShell

PolyShell exploite le endpoint d’upload de fichier des options de panier dans l’API REST de Magento :

POST /rest/default/V1/carts/{cartId}/items

Ce endpoint accepte un objet file_info contenant un fichier encodé en base64 — censé représenter une option produit de type “fichier joint”. Magento valide le fichier en vérifiant uniquement son en-tête pour détecter s’il s’agit d’une image.

L’attaque repose sur un fichier polyglotte : un fichier qui est simultanément une image valide et un script PHP exécutable. Il suffit de faire commencer le fichier par la signature GIF89a pour passer la validation, puis d’y glisser le payload PHP.

Trois lacunes de sécurité se cumulent :

  1. Aucune blacklist d’extension — les fichiers .php, .phtml et .phar sont acceptés
  2. Aucune vérification de l’option produit — l’upload se déclenche même si le produit n’a pas d’option de type fichier
  3. Validation MIME insuffisante — seul l’en-tête du fichier est contrôlé, pas son contenu réel

Le fichier uploadé atterrit dans pub/media/custom_options/quote/. Si la configuration du serveur web autorise l’exécution PHP dans ce répertoire, l’attaquant n’a plus qu’à appeler l’URL du fichier pour obtenir une exécution de code à distance (RCE).

Pour obtenir un SKU produit et un identifiant de panier invité — les seules données nécessaires à l’attaque — l’API GraphQL publique de Magento suffit. Aucun compte n’est requis.

Ce que les attaquants font une fois entrés

Les campagnes d’exploitation observées incluent :

  • Injection de skimmers JavaScript dans les pages CMS et blocs statiques, pointant vers des domaines malveillants (lanhd6549tdhse.top, jslibrary.net, canevaslab.com) pour exfiltrer les données de paiement des visiteurs
  • Dépôt de backdoors persistants nommés accesson.php dans plusieurs répertoires pour maintenir l’accès même après nettoyage partiel
  • Prise de contrôle complète du serveur dans les cas où la configuration PHP le permet

Versions affectées

  • Magento Open Source : toutes les versions jusqu’à 2.4.8 inclus
  • Adobe Commerce : toutes les versions jusqu’à 2.4.8 inclus

Le correctif est intégré dans la 2.4.9, actuellement en pré-release. Aucun patch isolé n’a été publié officiellement pour les versions de production stables — d’où l’importance des mesures ci-dessous.

Comment savoir si vous avez été attaqué

1. Scanner les fichiers uploadés suspects

Tout fichier .php, .phtml ou .phar dans pub/media/custom_options/ est un indicateur de compromission :

find pub/media/custom_options/ -type f \
  ! -name '.htaccess' \
  ! -name '*.png' \
  ! -name '*.jpg' \
  ! -name '*.gif' \
  ! -name '*.jpeg'

2. Chercher les backdoors

find . -name 'accesson.php' 2>/dev/null

3. Détecter les injections dans les pages CMS

grep -r "lanhd6549tdhse.top\|jslibrary.net\|canevaslab.com" pub/ app/ 2>/dev/null

Inspectez également vos pages CMS et blocs statiques depuis l’admin Magento à la recherche de balises <script> inattendues ou de code JavaScript obfusqué.

4. Analyser les logs d’accès

Recherchez des requêtes POST suspectes vers le endpoint de panier avec un paramètre file_info contenant du base64 volumineux :

POST /rest/default/V1/carts/*/items

Une rafale de ces requêtes sur une courte période, venant d’adresses IP inconnues, est un signal d’alerte fort.

Comment patcher

Option A — Patch officiel Magento (priorité absolue)

Le correctif a été extrait directement du commit de correction intégré dans la 2.4.9. Il est applicable sur votre installation actuelle :

# Télécharger le patch
curl -O https://github.com/magento/magento2/commit/796c4ce195cee0814ac92e5a19fc2ecfa79dae69.patch

# Appliquer
patch -p1 < 796c4ce195cee0814ac92e5a19fc2ecfa79dae069.patch

Vérifiez en staging avant d’appliquer en production. Ce patch corrige les trois lacunes de validation décrites plus haut : blacklist d’extensions, vérification des option IDs et validation stricte du contenu uploadé.

Option B — Blocage au niveau du serveur web

Si le patch ne peut pas être appliqué immédiatement, bloquez l’exécution PHP dans le répertoire d’upload.

Nginx — à ajouter dans votre configuration de virtualhost :

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

Apache — dans votre .htaccess ou la configuration du virtualhost :

<Directory /var/www/html/pub/media/custom_options>
    php_flag engine off
    AddType text/plain .php .phtml .phar
    Deny from all
</Directory>

Redémarrez votre serveur web après modification. Cette mesure empêche l’exécution des fichiers déjà uploadés et limite le risque d’exploitation active.

Option C — Module tiers

En dernier recours, si aucune des options précédentes n’est applicable dans votre environnement :

  • markshust/magento-polyshell-patch sur GitHub

Ce module Composer applique les corrections de validation directement dans le code Magento. À utiliser uniquement si le patch officiel (option A) ne peut pas être appliqué.

Si vous avez été compromis : procédure de nettoyage

  1. Isoler — Si l’infection est confirmée, passez la boutique en mode maintenance le temps du nettoyage
  2. Supprimer les fichiers suspects — Videz pub/media/custom_options/ après avoir sauvegardé son contenu pour analyse
  3. Supprimer les backdoors — Cherchez et supprimez tous les accesson.php et autres scripts inconnus
  4. Nettoyer les pages CMS — Retirez tout code JavaScript injecté depuis l’admin Magento
  5. Réinitialiser les accès — Changez tous les mots de passe admin et invalidez les sessions actives
  6. Auditer les logs — Remontez les logs d’accès pour identifier d’autres points d’entrée potentiels
  7. Appliquer le patch — Une fois nettoyée, appliquez le patch avant de remettre la boutique en ligne

En résumé

PolyShell est une faille sérieuse, activement exploitée, qui ne requiert aucune authentification. Si votre boutique tourne sur Magento 2.4.8 ou une version antérieure et que vous n’avez pas encore appliqué de mesure corrective, c’est une priorité immédiate.

La vérification initiale prend moins de 10 minutes avec les commandes ci-dessus.

Vous souhaitez qu’un expert audite votre boutique et applique le patch pour vous ? Contactez-nous — nous intervenons sous 48h.