Le 17 mars 2026, l’équipe forensic de Sansec a publié les détails d’une vulnérabilité critique baptisée PolyShell. Elle touche toutes les versions de Magento Open Source et Adobe Commerce, et permet à un attaquant non authentifié d’uploader un fichier exécutable via l’API REST. Aucun patch n’est disponible pour les versions de production. Voyons ce que ça implique concrètement et comment réagir.
Ce que PolyShell exploite
Le nom fait référence à la technique d’attaque : un fichier polyglotte, capable de se faire passer pour une image tout en embarquant du code exécutable. Un webshell déguisé.
La faille cible le flux REST des custom options de type file sur les produits du panier. Quand une option de ce type existe, Magento traite un objet file_info contenant les données en base64, un type MIME et un nom de fichier. Le fichier est ensuite écrit dans pub/media/custom_options/quote/, sans contrôle suffisant sur son contenu réel ni sur son extension.
Deux points à retenir :
Le code vulnérable est présent depuis la toute première release de Magento 2.
Les mutations GraphQL empruntent un autre chemin de code et ne sont pas affectées.
Toutes les boutiques ne sont pas exposées de la même manière
L’upload non authentifié concerne tout le monde. En revanche, le niveau de gravité dépend ensuite de la configuration serveur.
Stored XSS (exécution de JavaScript dans le navigateur d’un admin) : versions antérieures à 2.3.5, ou configurations serveur exposant publiquement le répertoire d’upload.
RCE (exécution de code à distance) : configurations nginx stock des versions 2.0.0 à 2.2.x via un nom de fichier index.php, toute configuration nginx passant les .php à FastCGI sans restriction, et configurations Apache antérieures à 2.3.5 sans php_flag engine 0.
En clair, deux boutiques avec le même bug applicatif peuvent se retrouver à des niveaux de risque très différents. Le problème ne se limite pas au code. Il se joue à l’intersection entre le code, la config serveur et les choix de l’hébergeur.
Ce que dit Sansec, ce que dit Adobe
C’est le point qui demande le plus de rigueur, parce qu’il y a une tension entre les deux lectures.
Côté Sansec, le message est clair. Le correctif n’existe que dans la version 2.4.9-alpha3, qui est une pré-release. Pas de patch isolé, pas de backport vers les branches de production. Sansec n’a pas observé d’exploitation active au moment de la publication, mais indique que la méthode d’exploit circule déjà.
Côté Adobe, le bulletin APSB25-94 (octobre 2025) documente bien des versions affectées et des versions corrigées sur les branches de prod : 2.4.8-p3, 2.4.7-p8, 2.4.6-p13, 2.4.5-p15, 2.4.4-p16. Mais ce bulletin couvre plusieurs CVE. La question est : est-ce que le correctif spécifique à PolyShell fait partie de ce qui a été backporté ?
Sansec écrit noir sur blanc : « Patched — 2.4.9-alpha3+ (pre-release only) ». Si le fix avait été présent dans les releases de sécurité d’octobre 2025, on voit mal pourquoi ils publieraient un avertissement urgent en mars 2026 en disant qu’il n’y a pas de correctif pour la production.
Il ne faut donc pas confondre « APSB25-94 contient des patches pour les branches de prod » (vrai, pour d’autres CVE) avec « le fix PolyShell est dans ces patches » (contredit par Sansec). Cette nuance change tout pour quelqu’un qui doit décider quoi faire maintenant.
Ce qu’on sait au 23 mars 2026 : les releases les plus récentes sont les 2.4.8-p4, 2.4.7-p9, 2.4.6-p14 et 2.4.5-p16 (bulletin APSB26-05, publiées le 10 mars). Montez dessus si ce n’est pas fait : elles corrigent d’autres vulnérabilités critiques. Mais ne partez pas du principe que ça suffit pour PolyShell.
Ce qu’il faut faire maintenant
En l’absence de correctif applicatif pour la production, le plan d’action repose sur trois axes : durcir, vérifier, nettoyer.
Tester votre exposition
Un curl suffit pour vérifier si le répertoire est accessible publiquement :
bash
curl -I https://votre-boutique.com/media/custom_options/Vous devriez obtenir un 403 Forbidden. Si vous obtenez un 200 ou un listing, il faut agir immédiatement.
Bloquer l’accès au répertoire
Bloquer l’accès public ne supprime pas la possibilité d’upload (le fichier continue d’atterrir via l’API), mais ça empêche l’accès direct au contenu déposé. C’est une mitigation, pas un correctif.
Pour nginx, assurez-vous qu’un bloc de restriction existe et qu’il n’est pas contourné par une règle regex plus large :
nginx
location /media/custom_options {
deny all;
return 403;
}Attention : une règle location ~ \.php$ positionnée avant peut matcher en priorité. C’est un classique qui peut ruiner la protection.
Pour Apache, ne vous contentez pas de vérifier qu’un .htaccess « existe ». Si votre AllowOverride est à None au niveau du vhost, il ne sert à rien. Même chose si une configuration personnalisée reprend la main plus haut.
Contrôler ce qui est déjà sur le disque
bash
Il ne faut pas raisonner uniquement en « je cherche des .php« . Cherchez toute extension douteuse et tout fichier récemment créé :
find pub/media/custom_options/ -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.pht" \)bash
find pub/media/custom_options/ -type f -mtime -30Sansec précise qu’eComscan a été mis à jour avec des patterns de détection spécifiques à PolyShell dès le 17 mars. C’est une option pour un scan plus systématique.
Le piège à ne pas oublier
Même si le fichier déposé n’est pas exécutable aujourd’hui, il reste sur le disque. Une migration de serveur, un changement de vhost, une config nginx un peu trop ouverte, et ce qui semblait contenu devient exploitable. C’est pour ça qu’un simple durcissement serveur ne suffit pas. Il faut durcir, vérifier, puis nettoyer.
Un rappel utile
Si votre boutique tourne sur une version hors support (en dessous de 2.4.6 pour Magento Open Source, en dessous de 2.4.4 pour Adobe Commerce avec extended support), la question n’est plus vraiment « comment contourner PolyShell ». La question, c’est combien de temps vous continuez à empiler du risque sur une base qui n’est plus maintenue. PolyShell est un révélateur, mais sur une boutique avec trois ans de retard sur les patches, c’est loin d’être le seul problème.
