PolyShell : 56,7% des boutiques Magento vulnérables déjà ciblées
Les attaques PolyShell sont passées en exploitation de masse seulement deux jours après divulgation. Si votre boutique Magento ou Adobe Commerce n'est pas corrigée, la fenêtre de risque est déjà ouverte.
Résumé de l'alerte
- 56,7% des boutiques vulnérables observées sont déjà ciblées en exploitation active.
- Début de l'exploitation de masse le 19 mars 2026.
- Le bug impacte Magento Open Source 2 et Adobe Commerce via l'API REST.
- Risque principal : RCE, takeover de compte, et enchaînement vers skimmer carte bancaire.
Ce que l'on sait de PolyShell
Selon les informations publiées par BleepingComputer et les travaux de Sansec, l'attaque exploite une faiblesse de l'API REST Magento liée aux uploads de fichiers dans les options personnalisées du panier. Le mécanisme permet d'injecter des fichiers polyglottes qui peuvent, selon la configuration serveur, 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 le correctif n'était pas encore disponible en version stable au moment des premières vagues d'attaques massives.
Pourquoi ce chiffre de 56,7% est préoccupant
Dans le monde e-commerce, un taux de ciblage aussi élevé en si peu de temps indique une automatisation agressive : scanners internet, fingerprinting de versions, et exécution opportuniste à grande échelle. Cela signifie que les attaquants ne cherchent pas des cibles spécifiques, ils exploitent tout ce qui répond.
Pour un commerçant ou une PME, la conséquence est immédiate : même sans être une "grosse" marque, vous êtes dans la zone de tir si votre stack est exposée.
Le second étage : skimmer WebRTC
Sansec signale aussi une campagne où les opérateurs déploient un skimmer de carte bancaire inédit exploitant WebRTC pour l'exfiltration. C'est important car WebRTC peut contourner certaines logiques de surveillance réseau orientées HTTP classique.
Le scénario décrit : un loader JavaScript léger ouvre une communication chiffrée vers un C2, récupère un payload secondaire et l'exécute en contournant des protections CSP (réutilisation de nonce, fallback unsafe-eval, injection script). L'exécution différée via requestIdleCallback vise à réduire la détection.
Autrement dit : l'attaque ne cherche pas seulement à entrer, elle cherche à rester discrète tout en capturant des données de paiement.
Impact business réel pour une boutique en ligne
Perte de revenus immédiate
Blocage des paiements, mise en maintenance d'urgence, chute du taux de conversion.
Risque légal et conformité
Exposition de données clients, obligations de notification, responsabilités RGPD/contractuelles.
Atteinte à la réputation
Perte de confiance durable, hausse du coût d'acquisition et baisse de fidélité.
Coût de remédiation
Forensic, nettoyage, re-déploiement, supervision renforcée et audit post-incident.
Plan d'action prioritaire (0-72h)
1. Réduire la surface immédiatement
- Bloquer temporairement les routes API non indispensables et durcir WAF/règles reverse proxy.
- Limiter les uploads à des types stricts et valider côté serveur (MIME + extension + contenu).
- Désactiver les modules custom suspects ou non maintenus.
2. Corriger et valider
- Appliquer le patch fournisseur dès disponibilité stable.
- Tester sur préproduction avec scénarios checkout + API + options panier.
- Vérifier les permissions filesystem et l'exécution PHP (principe du moindre privilège).
3. Chasser la compromission
- Analyser les logs applicatifs, web et WAF sur la fenêtre depuis le 19 mars.
- Rechercher IOC publiés par Sansec (IP de scan, patterns JS skimmer, anomalies WebRTC).
- Auditer le front checkout (scripts injectés, nonce CSP, appels externes inattendus).
4. Contenir le risque paiement
- Activer supervision temps réel sur pages panier/checkout.
- Isoler les composants de paiement, revoir les clés API et secrets d'intégration.
- Mettre en place un contrôle d'intégrité des scripts front (SRI, allowlist CSP stricte).
Hardening recommandé après crise
Une fois l'urgence traitée, la priorité est d'éviter la prochaine vague. Dans les environnements e-commerce, l'attaque initiale passe souvent par le web, mais le dommage vient de la persistance et de la discrétion des payloads.
- Pipeline de patch management plus court (SLA sécurité explicite)
- Audit de code des extensions tierces
- Journalisation centralisée + alertes sur modifications checkout
- Scan régulier de sécurité applicative et test d'intrusion ciblé e-commerce
- Plan de réponse incident spécifique "skimmer paiement"
FAQ express
Notre boutique n'a pas de trafic énorme. Sommes-nous concernés ?
Oui. L'exploitation est automatisée et opportuniste. Les attaquants ciblent des versions vulnérables, pas des marques célèbres.
Un WAF suffit-il à nous protéger ?
Non. Le WAF aide à réduire l'exposition, mais ne remplace pas le patching, le durcissement API et l'analyse de compromission.
Pourquoi WebRTC complique la détection ?
Parce que l'exfiltration ne ressemble pas toujours à des appels HTTP classiques et peut contourner une surveillance centrée sur CSP/connect-src.
Sources
BleepingComputer (Bill Toulas, 25 mars 2026) et recherches Sansec sur l'exploitation PolyShell et le skimmer WebRTC associé.
Articles liés sur ce blog
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
Méthode pour évaluer l'exposition réelle de votre SI.
Sécurité email pour commerçants
Compléter la sécurité e-commerce côté identité et phishing.
Règle 3-2-1-1-0
Préparer la reprise après incident avec une sauvegarde robuste.
Votre boutique en ligne est-elle réellement protégée contre ce type d'attaque ?
Je vous accompagne sur l'audit sécurité e-commerce, le plan de patch, le hardening applicatif et la surveillance anti-skimmer pour limiter le risque business.
Nous Contacter