PolyShell : la faille Magento 2 qui touche 80 % des boutiques

Le 17 mars 2026, l'équipe Sansec Forensics a divulgué PolyShell, une vulnérabilité critique dans l'API REST de Magento 2 et Adobe Commerce. Le bug permet l'upload de fichiers PHP exécutables sans authentification, et il est présent depuis la première version de Magento 2 — toutes les versions stables sont concernées.

Qu'est-ce que PolyShell ?

PolyShell est une faille d'upload non restreint exploitée via les options personnalisées des articles du panier invité. Le terme « polyshell » vient du fichier polyglotte utilisé par les attaquants : un fichier valide à la fois comme image GIF (header GIF89a) et comme script PHP exécutable.

Trois contrôles sont absents du code Magento :

1. Pas de validation de l'ID d'option produit soumis
2. Pas de vérification du type d'option réel
3. Pas de restriction d'extension (.php, .phtml, .phar sont autorisés)

La seule validation effectuée est un appel à getimagesizefromstring() sur l'en-tête du fichier — trivialement contournable en injectant un préfixe d'image valide devant le payload PHP.

Endpoints vulnérables

POST /V1/guest-carts/:cartId/items
PUT  /V1/guest-carts/:cartId/items/:itemId

Ces endpoints sont accessibles sans authentification. Les fichiers uploadés sont écrits dans pub/media/custom_options/quote/.

Versions affectées

Chronologie de l'exploitation

• 16 mars 2026 — premières tentatives d'exploitation détectées (12:00 UTC)
• 19 mars — début du scan automatisé massif
• 23 mars — 23 % des boutiques scannées
• 24 mars — 56,7 % des boutiques touchées par des uploads PHP malveillants ; un retailer à 100 milliards de dollars compromis avec un skimmer WebRTC
• 30 mars — 79,5 % des boutiques visées ; déploiement actif de backdoors et de loaders JavaScript
• 14 avril — 82 % de l'écosystème touché

Auditer son Magento : commandes à lancer

Lister les fichiers suspects dans le dossier d'upload

find pub/media/custom_options/ -type f ! -name '.htaccess'

Toute extension .php, .phtml ou .phar dans ce répertoire est un indicateur de compromission direct.

Rechercher la backdoor accesson.php

find /var/www -name 'accesson.php' -type f 2>/dev/null

Cette backdoor secondaire est dispersée par les attaquants dans plusieurs répertoires :

var/assets/images/accesson.php
vendor/assets/images/accesson.php
pub/assets/images/accesson.php
app/assets/images/accesson.php
lib/assets/images/accesson.php
bin/assets/images/accesson.php
setup/assets/images/accesson.php
generated/assets/images/accesson.php

Repérer les patterns d'évaluation dans les fichiers PHP

find pub/media/custom_options/ -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)
grep -rE 'eval\s*\(\s*base64_decode' pub/ var/ generated/ 2>/dev/null

Indicateurs de compromission

Noms de fichiers observés en attaques

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, accesson.php, toggige-arrow.jpg.

Pattern récurrent : [optionID]index.php (par exemple 780index.php).

Domaines de chargement de payload JavaScript

• lanhd6549tdhse[.]top
• jslibrary[.]net
• canevaslab[.]com

Signature beacon

La backdoor accesson.php retourne systématiquement la valeur 8194460 (résultat de 409723 × 20) comme empreinte. C'est une signature unique exploitable pour grep réseau ou pour détecter les shells actifs sur un serveur déjà compromis.

Se protéger : configurations à appliquer

Nginx

Insérer ce bloc avant tout location ~ \.php$ dans la config du virtual host Magento :

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

Apache

Créer ou modifier le fichier .htaccess dans pub/media/custom_options/ :

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

Recommandations

• Lancer immédiatement les commandes d'audit ci-dessus sur tous les environnements de production
• Appliquer la configuration Nginx ou Apache dès aujourd'hui
• Mettre en place un cron de scan sur pub/media/custom_options/ avec alerte par e-mail en cas de fichier non-image
• Envisager un WAF dédié Magento (Sansec Shield, eComscan ou équivalent) pour intercepter les tentatives en temps réel
• Surveiller les annonces Adobe pour le rétroportage du correctif sur la branche 2.4.x
• En cas de compromission avérée : isoler la machine, dumper la base, restaurer depuis un backup antérieur au 16 mars 2026 et changer toutes les clés (API, admin, intégrations tierces)

Conclusion

PolyShell est l'une des failles les plus critiques de l'année pour l'écosystème Magento : non authentifiée, exploitée massivement, sans patch isolé pour les versions stables. Tant qu'Adobe ne publie pas de rétroportage, les mitigations décrites ici sont la seule barrière entre une boutique et une RCE complète.

Sources :

• Article original Sansec : sansec.io/research/magento-polyshell
• Bulletin Adobe APSB25-94