PolyShell : la faille Magento silencieuse — détecter et se protéger

Votre boutique Magento tourne peut-être depuis des années sans le moindre problème apparent. Mais depuis quelques mois, une faille baptisée PolyShell fait parler d’elle dans le monde de la sécurité e-commerce. Et pour cause : elle existe dans Magento depuis la toute première version, elle est facile à exploiter, et la majorité des boutiques en production sont encore exposées.

Ce n’est pas une alerte théorique. Des centaines de boutiques françaises ont déjà été compromises via ce vecteur — webshells cachés, skimmers de cartes bancaires, comptes administrateurs créés à l’insu du marchand. Voici ce que vous devez savoir.

C’est quoi exactement, PolyShell ?

PolyShell est le nom donné à une vulnérabilité dans la gestion des options de fichiers personnalisées de Magento. Concrètement, Magento permet à vos clients de joindre des fichiers à leurs commandes — une gravure, un logo, un bon de commande. Le problème : le mécanisme qui reçoit ces fichiers ne vérifie pas correctement leur nature réelle.

Un attaquant peut envoyer un fichier qui se fait passer pour une image mais contient en réalité du code PHP malveillant. Une fois ce fichier déposé sur votre serveur, il suffit de l’appeler depuis un navigateur pour exécuter n’importe quelle commande sur votre hébergement. C’est ce qu’on appelle un webshell — une porte dérobée permanente sur votre site.

Comment fonctionne une attaque PolyShell

1. Upload

Fichier PHP

Déguisé en image via REST API

2. Dépôt

Stockage serveur

Fichier dans pub/media/

3. Activation

Appel URL direct

Depuis n’importe quel navigateur

4. Contrôle total

Accès serveur complet

Vol de données clients

Webshell

Porte dérobée permanente — exécution de code à distance

Skimmer JS

Vol de numéros de carte bancaire au checkout

Admin frauduleux

Compte administrateur créé à votre insu

Déroulement type d’une attaque PolyShell sur une boutique Magento 2

Comment savoir si votre boutique est touchée ?

C’est là que ça devient inquiétant : dans la majorité des cas, les marchands ne s’aperçoivent de rien. Les fichiers malveillants sont discrets, ne perturbent pas le fonctionnement du site, et peuvent rester actifs pendant des mois — parfois des années. Voici les signes qui doivent vous alerter :

• Des fichiers .php inattendus dans pub/media/ — ce dossier ne devrait contenir que des images et documents, jamais de code PHP
• Un ou plusieurs comptes administrateurs que vous ne reconnaissez pas dans Magento → Système → Tous les utilisateurs
• Des modifications inexpliquées dans vos blocs CMS — notamment les blocs affichés au checkout
• Des alertes Google Search Console signalant du contenu malveillant ou des pages inconnues
• Une consommation serveur anormale sans pic de trafic correspondant

Comment détecter les fichiers malveillants ?

Si vous avez un accès SSH à votre serveur, cette commande permet de repérer tous les fichiers PHP qui n’ont rien à faire dans le dossier media :

find pub/media/ -name "*.php" -type f

Si cette commande retourne des résultats, vous avez très probablement été compromis. Un résultat vide est rassurant — mais pas une garantie absolue, car certains webshells utilisent des extensions différentes (.phtml, .php3, .phar).

find pub/media/ -name "*.phtml" -o -name "*.php3" -o -name "*.phar" | xargs ls -la 2>/dev/null

Quelles versions sont concernées ?

Toutes les versions de Magento 2 jusqu’à la 2.4.8 incluse sont potentiellement exposées selon la configuration du serveur web. Adobe a intégré un correctif dans la version 2.4.9 (actuellement en beta), mais aucun patch isolé n’existe pour les versions en production. La protection passe donc par des mesures de mitigation côté serveur, pas par une simple mise à jour de Magento.

Statut des versions Magento face à PolyShell

2.4.4 — 2.4.5

Fin de support

Plus de correctifs — exposition maximale

Migrez d’urgence

2.4.6 — 2.4.8

Exposées

Pas de patch isolé — mitigation serveur nécessaire

Config serveur requise

2.4.9 (beta)

Corrigée

Patch APSB25-94 intégré — pas encore stable en prod

La solution

Configuration serveur

La protection passe par le serveur, pas par Magento

État de la vulnérabilité PolyShell selon la version Magento — juin 2026

Les mesures de protection à mettre en place

En attendant un correctif officiel pour les versions en production, la parade la plus efficace est de bloquer l’exécution de PHP dans les dossiers publics qui ne devraient jamais contenir de code. Concrètement, cela se fait dans la configuration de votre serveur web (Apache ou Nginx).

Sur Apache, il faut s’assurer que le fichier .htaccess de pub/media/ contient bien des règles qui interdisent l’exécution de scripts PHP. Sur Nginx, c’est une directive location qui fait le travail. Si vous n’êtes pas à l’aise avec ces configurations, c’est exactement le type d’intervention qu’un prestataire Magento peut réaliser en moins d’une heure.

Autres mesures complémentaires recommandées :

• Auditer les comptes administrateurs : supprimez tout compte que vous ne reconnaissez pas
• Vérifier les blocs CMS sensibles : notamment ceux affichés en page de paiement
• Activer la surveillance des fichiers : certains outils comme Sansec alertent en temps réel sur toute modification suspecte
• Restreindre l’accès à l’admin par IP si possible — moins d’exposition, moins de risques

Et si votre boutique a déjà été compromise ?

Ne paniquez pas, mais n’attendez pas non plus. La priorité est de couper le mal à la racine : supprimer les fichiers malveillants, révoquer les accès frauduleux, et identifier la durée d’exposition pour évaluer si des données clients ont pu être volées. Si des données de cartes bancaires sont en jeu, une notification à la CNIL est obligatoire dans les 72 heures.

Une boutique nettoyée sans renforcement des protections sera recompromise en quelques jours. Le nettoyage et la sécurisation doivent aller de pair.