Une campagne Magecart exploite la faille PolyShell dans Magento 2 pour déployer un skimmer de paiement utilisant WebRTC afin de contourner la Content Security Policy. 56 % des boutiques vulnérables sont déjà ciblées, sans patch stable disponible.
En bref
- PolyShell est une vulnérabilité critique dans Magento Open Source v2 et Adobe Commerce v2 permettant l'exécution de code à distance sans authentification via l'API REST.
- Les attaquants déploient un skimmer JavaScript qui exfiltre les données de paiement via WebRTC (UDP/DTLS), contournant complètement la Content Security Policy (CSP).
- 56,7 % des boutiques Magento vulnérables sont déjà ciblées ; le seul patch disponible est en version bêta (Adobe Commerce 2.4.9-beta1) et n'a pas encore rejoint la branche stable.
PolyShell : quand l'API Magento devient une porte dérobée
Depuis le 19 mars 2026, les équipes de Sansec et BleepingComputer documentent une vague d'attaques massives ciblant les boutiques Magento Open Source v2 et Adobe Commerce v2. La faille exploitée, baptisée PolyShell par les chercheurs, permet à un attaquant non authentifié d'uploader des fichiers exécutables arbitraires via l'API REST de Magento. Le mécanisme d'abus réside dans la gestion des options personnalisées des articles du panier, qui accepte des chargements de fichiers sans validation suffisante du type MIME ni contrôle d'autorisation. Une fois un fichier PHP malveillant déposé, l'attaquant dispose d'un accès shell complet au serveur.
Plus de 50 adresses IP différentes scannent activement Internet à la recherche de boutiques vulnérables, selon Sansec. Parmi les victimes confirmées figure le site e-commerce d'un constructeur automobile valorisé à plus de 100 milliards de dollars, qui n'avait pas encore appliqué le correctif bêta au moment de la divulgation. Adobe a publié un correctif le 10 mars 2026 dans la version 2.4.9-beta1, mais celui-ci n'a pas encore rejoint la branche stable de production — laissant la grande majorité des boutiques sans solution officielle stable.
Le skimmer WebRTC : une évolution qui annule la CSP
Une fois l'accès initial obtenu via PolyShell, les attaquants injectent un skimmer JavaScript de nouvelle génération dans les pages de paiement. L'innovation technique de cette campagne réside dans le canal d'exfiltration : au lieu d'envoyer les données de carte bancaire volées via une requête HTTP/HTTPS classique — bloquable par une règle Content Security Policy — le skimmer ouvre une connexion WebRTC data channel chiffrée en DTLS sur UDP. La CSP, qui ne contrôle que les flux HTTP, est ainsi totalement contournée. Le skimmer utilise également l'API requestIdleCallback pour retarder son exécution et échapper aux outils d'analyse comportementale qui surveillent les actions au moment du chargement de la page.
Cette technique marque une évolution majeure dans les attaques de type Magecart. Pour les propriétaires de boutiques en ligne, cela signifie que même une politique CSP rigoureuse ne constitue plus une défense suffisante contre les skimmers modernes. Des mécanismes complémentaires — monitoring de l'intégrité des fichiers, analyse du trafic réseau sortant incluant UDP, et intégration PCI DSS d'un WAF applicatif — deviennent indispensables.
Ce qu'il faut retenir
- Appliquez immédiatement le patch Adobe Commerce 2.4.9-beta1 si vous opérez une boutique Magento, ou implémentez les règles de blocage WAF publiées par Sansec en attendant le patch stable.
- La CSP seule ne suffit plus : les skimmers modernes utilisent WebRTC (UDP) pour exfiltrer les données en contournant toutes les politiques HTTP.
- Auditez l'intégrité de vos fichiers Magento (en particulier sous
pub/mediaetvar/) pour détecter tout fichier PHP non autorisé déposé via l'API REST.
Comment protéger ma boutique Magento contre PolyShell si le patch stable n'est pas encore disponible ?
En attendant le patch stable, trois mesures d'urgence : (1) bloquez les uploads de fichiers via l'API REST Magento au niveau du WAF ou du reverse proxy en filtrant les requêtes POST vers les endpoints /rest/*/V1/carts/*/items qui contiennent des fichiers ; (2) activez la surveillance de l'intégrité des fichiers pour détecter tout nouveau fichier PHP dans les répertoires publics ; (3) bloquez les connexions WebRTC sortantes au niveau réseau si votre boutique n'en a pas besoin. Les signatures de détection publiées par Sansec permettent également d'identifier le skimmer dans vos fichiers JavaScript.
Besoin d'un accompagnement expert ?
Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.
Prendre contactÀ propos de l'auteur
Ayi NEDJIMI
Expert Cybersécurité Offensive & Intelligence Artificielle
Ayi NEDJIMI est un expert senior en cybersécurité offensive et intelligence artificielle avec plus de 20 ans d'expérience. Spécialisé en rétro-ingénierie, forensics numériques et développement de modèles IA, il accompagne les organisations dans la sécurisation d'infrastructures critiques.
Expert judiciaire et conférencier reconnu, il intervient auprès des plus grandes organisations françaises et européennes. Ses domaines couvrent l'audit Active Directory, le pentest cloud (AWS, Azure, GCP), la rétro-ingénierie de malwares et l'IA générative (RAG, LLM).
Ressources & Outils de l'auteur
Articles connexes
Conduent : brèche SafePay expose 25 millions d'Américains
SafePay ransomware a compromis Conduent entre octobre 2024 et janvier 2025, exfiltrant 8,5 To de données sur 25 millions de citoyens bénéficiaires de prestations sociales américaines. Les notifications aux victimes n'ont débuté que 9 mois après la découverte.
Qilin cible Malaysia Airlines : données passagers volées
Le groupe Qilin ransomware revendique une intrusion dans les systèmes de Malaysia Airlines, exposant potentiellement dossiers de réservation, données d'employés et contrats fournisseurs. La compagnie n'a pas officiellement confirmé la brèche à ce jour.
CVE-2026-33017 Langflow : RCE non authentifié exploité
CVE-2026-33017 affecte Langflow ≤ 1.8.1 avec un score CVSS 9.3 : exécution de code Python sans authentification via l'API publique. La CISA a inscrit la faille au catalogue KEV le 25 mars 2026, après exploitation active détectée 20 heures après la divulgation.
Commentaires
Aucun commentaire pour le moment. Soyez le premier à commenter !
Laisser un commentaire