Illustration technique de l'attaque PolyShell ciblant les boutiques Magento et Adobe Commerce
Retour au blog
Sécurité

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.

Kévin Moniaux
26 mars 2026 6 min de lecture
Sommaire8 sections
  1. Ce que l'on sait de la vulnérabilité PolyShell
  2. Pourquoi 56,7% des boutiques Magento sont-elles ciblées par PolyShell ?
  3. Le second étage de l'attaque : le skimmer WebRTC
  4. Impact business réel pour une boutique en ligne
  5. Plan d'action prioritaire (0-72h) pour sécuriser votre e-commerce
  6. 1. Réduire la surface d'attaque immédiatement
  7. 2. Corriger et valider l'infrastructure
  8. 3. Chasser la compromission (Threat Hunting)
  9. 4. Contenir le risque lié aux paiements
  10. Hardening recommandé après crise par Le Bon Contact
  11. Foire Aux Questions (FAQ) sur PolyShell et Magento
  12. 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

🧰 Un outil gratuit pour aller plus loin
Sans inscription, et sans engagement — vous avez une réponse chiffrée en quelques minutes.
🛡️
Test de vulnérabilité →
Votre site est-il vulnérable ? On repère les faiblesses visibles — version exposée, portes ouvertes — sans rien forcer.
📬 Les prochains articles, une fois par semaine
Dépannage, sécurité, logiciels : ce qui est utile, sans bruit. Désinscription en un clic.
Partager : Facebook X LinkedIn WhatsApp E-mail

Besoin de sécuriser votre boutique e-commerce ?

Ne laissez pas la faille PolyShell menacer votre activité. Contactez Le Bon Contact pour un audit et une sécurisation de votre infrastructure Magento à Agen et dans le Lot-et-Garonne.

Demander un audit de sécurité

Un besoin informatique près de chez vous ?

Le Bon Contact intervient dans votre secteur :

Articles similaires