PolyShell 2026 : 56,7% des boutiques Magento et Adobe Commerce ciblées
Les attaques PolyShell exploitent massivement une faille de l'API Magento depuis mars 2026. Si votre boutique n'est pas corrigée, le risque de vol de cartes bancaires est critique. Découvrez notre analyse technique et les mesures d'urgence.
Sommaire8 sections
- Ce que l'on sait de la vulnérabilité PolyShell
- Pourquoi 56,7% des boutiques Magento sont-elles ciblées par PolyShell ?
- Le second étage de l'attaque : le skimmer WebRTC
- Impact business réel pour une boutique en ligne
- Plan d'action prioritaire (0-72h) pour sécuriser votre e-commerce
- 1. Réduire la surface d'attaque immédiatement
- 2. Corriger et valider l'infrastructure
- 3. Chasser la compromission (Threat Hunting)
- 4. Contenir le risque lié aux paiements
- Hardening recommandé après crise par Le Bon Contact
- Foire Aux Questions (FAQ) sur PolyShell et Magento
- Articles liés sur la sécurité de votre système d'information
Résumé de l'alerte de sécurité :
- 56,7% des boutiques vulnérables observées sont déjà ciblées en exploitation active.
- Début de l'exploitation de masse repéré le 19 mars 2026.
- Le bug impacte Magento Open Source 2 et Adobe Commerce via l'API REST.
- Risque principal : RCE (exécution de code à distance), takeover de compte, et enchaînement vers un skimmer de carte bancaire.
Ce que l'on sait de la vulnérabilité PolyShell
Selon les informations publiées par BleepingComputer et les travaux de recherche de Sansec, l'attaque exploite une faiblesse critique de l'API REST Magento. Cette faille est spécifiquement liée aux uploads de fichiers dans les options personnalisées du panier d'achat. Le mécanisme défaillant permet aux pirates d'injecter des fichiers dits « polyglottes » (des fichiers valides sous plusieurs formats, par exemple une image qui contient également du code PHP exécutable).
Selon la configuration de votre serveur web, cette injection peut mener à une exécution de code à distance (RCE) ou à une compromission via XSS stocké. Adobe a introduit un correctif dans la branche 2.4.9-beta1 le 10 mars 2026, mais ce correctif n'était pas encore disponible en version stable au moment des premières vagues d'attaques massives, laissant une fenêtre d'opportunité béante pour les cybercriminels.
| Caractéristique | Détail de la vulnérabilité PolyShell |
|---|---|
| Cible principale | Magento Open Source 2 & Adobe Commerce |
| Vecteur d'attaque | API REST (options personnalisées du panier) |
| Type de charge utile | Fichiers polyglottes (contournement des filtres d'upload) |
| Impact technique | RCE (Exécution de code à distance) / XSS stocké |
| Correctif initial | Branche 2.4.9-beta1 (10 mars 2026) |
Pourquoi 56,7% des boutiques Magento sont-elles ciblées par PolyShell ?
Dans le monde du e-commerce, un taux de ciblage aussi élevé en si peu de temps indique une automatisation agressive. Les attaquants utilisent des scanners internet massifs, réalisent du fingerprinting de versions (identification automatique de la version de votre CMS), et exécutent leurs scripts de manière opportuniste à très grande échelle. Cela signifie qu'ils ne cherchent pas des cibles spécifiques ou de grandes marques : ils exploitent absolument tout ce qui répond positivement à leurs requêtes.
Pour un commerçant ou une PME, notamment dans le Lot-et-Garonne (autour de Agen et Villeneuve-sur-Lot) où Le Bon Contact accompagne de nombreux e-commerçants, la conséquence est immédiate. Même sans être une enseigne d'envergure nationale, vous êtes dans la zone de tir si votre infrastructure (stack technique) est exposée sur internet sans les derniers correctifs de sécurité.
Le second étage de l'attaque : le skimmer WebRTC
L'accès initial n'est que la première étape. Sansec signale une campagne sophistiquée où les opérateurs déploient un skimmer de carte bancaire inédit exploitant le protocole WebRTC pour l'exfiltration des données de paiement. C'est un point crucial car WebRTC (conçu à l'origine pour les communications audio/vidéo en temps réel) peut contourner la plupart des logiques de surveillance réseau orientées sur le trafic HTTP classique.
Le scénario technique décrit est le suivant : un loader JavaScript très léger ouvre une communication chiffrée peer-to-peer vers un serveur de commande et contrôle (C2). Il récupère ensuite un payload secondaire et l'exécute en contournant les protections CSP (Content Security Policy) via la réutilisation de nonce, un fallback unsafe-eval, ou l'injection directe de script. L'exécution est souvent différée via la fonction requestIdleCallback, ce qui vise à réduire la détection par les outils d'analyse comportementale du navigateur.
Autrement dit : l'attaque ne cherche pas seulement à pénétrer votre système, elle cherche à y établir une persistance extrêmement discrète tout en siphonnant les numéros de cartes bancaires de vos clients en temps réel.
Impact business réel pour une boutique en ligne
Une compromission de type PolyShell n'est pas qu'un problème informatique, c'est une crise majeure pour la pérennité de votre entreprise :
- Perte de revenus immédiate : Blocage des paiements par les prestataires, mise en maintenance d'urgence du site, et chute drastique du taux de conversion.
- Risque légal et conformité : Exposition des données personnelles et bancaires de vos clients, obligations strictes de notification à la CNIL, et lourdes responsabilités liées au RGPD et à la norme PCI-DSS.
- Atteinte à la réputation : Perte de confiance durable de votre clientèle, bad buzz sur les réseaux sociaux, hausse du coût d'acquisition client et baisse de la fidélité.
- Coût de remédiation : Frais d'investigation numérique (forensic), nettoyage complet des serveurs, re-déploiement sécurisé, supervision renforcée et audit post-incident.
Plan d'action prioritaire (0-72h) pour sécuriser votre e-commerce
1. Réduire la surface d'attaque immédiatement
- Bloquer temporairement les routes API non indispensables et durcir les règles de votre WAF (Web Application Firewall) ou reverse proxy.
- Limiter les uploads à des types MIME stricts et valider rigoureusement côté serveur (vérification de l'extension ET du contenu réel du fichier).
- Désactiver tous les modules custom suspects, obsolètes ou non maintenus par leurs éditeurs.
2. Corriger et valider l'infrastructure
- Appliquer le patch fourni par Adobe/Magento dès sa disponibilité en version stable.
- Tester impérativement sur un environnement de préproduction avec des scénarios complets : tunnel de commande (checkout), appels API et options du panier.
- Vérifier les permissions du système de fichiers (filesystem) et restreindre l'exécution PHP selon le principe du moindre privilège.
3. Chasser la compromission (Threat Hunting)
- Analyser les logs applicatifs, les logs web et ceux du WAF sur la fenêtre temporelle critique (depuis le 19 mars 2026).
- Rechercher les Indicateurs de Compromission (IOC) publiés par Sansec : adresses IP de scan connues, patterns JavaScript liés au skimmer, et anomalies de trafic WebRTC.
- Auditer le front-end de votre page de paiement : traquer les scripts injectés, vérifier les nonces CSP, et identifier tout appel externe inattendu.
4. Contenir le risque lié aux paiements
- Activer une supervision en temps réel spécifiquement sur les pages panier et checkout.
- Isoler les composants de paiement, révoquer et renouveler les clés API ainsi que les secrets d'intégration avec votre banque ou prestataire (Stripe, PayPal, etc.).
- Mettre en place un contrôle d'intégrité des scripts front-end (Subresource Integrity - SRI) et une allowlist CSP très stricte.
Hardening recommandé après crise par Le Bon Contact
Une fois l'urgence traitée, la priorité est d'éviter la prochaine vague d'attaques. Dans les environnements e-commerce, l'intrusion initiale passe souvent par une faille web classique, mais le véritable dommage financier provient de la persistance et de la discrétion des charges utiles (payloads).
En tant qu'experts en infogérance basés à Agen, nous recommandons à nos clients du Lot-et-Garonne et d'Nouvelle-Aquitaine de mettre en place les mesures suivantes :
- Raccourcir le pipeline de patch management (définir un SLA de sécurité explicite pour l'application des correctifs critiques).
- Réaliser un audit de code systématique des extensions tierces avant leur mise en production.
- Déployer une journalisation centralisée couplée à des alertes immédiates en cas de modification des fichiers liés au checkout.
- Planifier des scans réguliers de sécurité applicative et des tests d'intrusion ciblés sur la logique e-commerce.
- Rédiger et tester un plan de réponse à incident spécifique au scénario « skimmer de paiement ».
Foire Aux Questions (FAQ) sur PolyShell et Magento
Notre boutique n'a pas un trafic énorme. Sommes-nous réellement concernés par PolyShell ?
Oui, absolument. L'exploitation de cette faille est entièrement automatisée et opportuniste. Les attaquants déploient des robots qui scannent l'ensemble du web à la recherche de versions vulnérables de Magento, sans se soucier de la notoriété ou de la taille de la marque ciblée.
Un pare-feu applicatif (WAF) suffit-il à nous protéger contre ces attaques ?
Non. Bien qu'un WAF aide à réduire l'exposition initiale en bloquant certaines requêtes malveillantes connues, il ne remplace en aucun cas l'application des correctifs de sécurité (patching), le durcissement de votre API et une analyse approfondie pour vérifier qu'aucune compromission n'a déjà eu lieu.
Pourquoi l'utilisation du protocole WebRTC complique-t-elle la détection des vols de données ?
Le WebRTC permet d'établir des connexions directes (peer-to-peer) qui ne ressemblent pas aux appels HTTP classiques (comme les requêtes AJAX ou Fetch). Cela lui permet de passer sous le radar des outils de surveillance réseau traditionnels et de contourner les politiques de sécurité (CSP) qui se concentrent uniquement sur la directive connect-src.
Articles liés sur la sécurité de votre système d'information
- CISA en alerte : Zimbra, SharePoint et Cisco - Comment prioriser les correctifs quand l'exploitation est déjà active.
- Audit de sécurité informatique en entreprise - La méthode de Le Bon Contact pour évaluer l'exposition réelle de votre SI à Agen et dans le Lot-et-Garonne.
- Sécurité email pour commerçants - Compléter la sécurité de votre e-commerce en protégeant vos identités contre le phishing.
- La Règle de sauvegarde 3-2-1-1-0 - Préparer la reprise d'activité après un incident cyber avec une stratégie de sauvegarde robuste.
