FunnelKit WordPress : vol CB actif sur 40 000 boutiques

Comment les attaquants volent des données CB sur 40 000 boutiques WooCommerce

Une vulnérabilité critique affectant le plugin FunnelKit (Funnel Builder pour WooCommerce) est activement exploitée dans la nature depuis le 16 mai 2026, exposant potentiellement plus de 40 000 boutiques en ligne à des attaques de type web skimming. Les attaquants injectent du code JavaScript malveillant dans les pages de paiement WooCommerce pour dérober en temps réel les informations de carte bancaire, les codes CVV, les adresses de facturation et l'ensemble des données personnelles saisies par les acheteurs au moment du checkout. L'exploitation a été documentée en détail par les chercheurs de Wordfence et de The Hacker News.

FunnelKit, développé par la société éponyme, est l'un des plugins WordPress les plus populaires dans l'univers du e-commerce. Il permet aux marchands WooCommerce de personnaliser intégralement leurs tunnels de vente : pages de checkout optimisées, order bumps, upsells en un clic, et gestion avancée du parcours d'achat. Sa popularité — plus de 40 000 installations actives selon les données de WordPress.org — en fait une cible de choix pour les groupes cybercriminels spécialisés dans le vol de données de paiement, communément désignés sous le nom de Magecart.

La faille exploitée réside dans le gestionnaire de scripts externes du plugin. Toutes les versions antérieures à la version 3.15.0.3 permettent à un attaquant non authentifié d'injecter du JavaScript arbitraire dans le paramètre External Scripts des paramètres de checkout de FunnelKit. Cette absence totale de vérification d'authentification et de validation des entrées dans le gestionnaire AJAX concerné est particulièrement grave dans un composant directement lié aux pages de paiement. N'importe quelle requête HTTP forgée peut exploiter cette ouverture, sans nécessiter le moindre compte ou privilège sur le site ciblé.

La méthode d'attaque observée par les chercheurs est sophistiquée dans sa capacité à se dissimuler au milieu du code légitime. Les attaquants insèrent dans le champ de scripts externes un loader imitant le format d'un script Google Tag Manager (GTM) légitime. Ce choix est délibéré et calculé : GTM est universellement présent sur les sites e-commerce pour le suivi analytique et marketing, et sa présence dans le code source d'une page ne suscite généralement aucun soupçon de la part des administrateurs qui effectueraient un audit superficiel des scripts chargés sur leur boutique.

Le script GTM frauduleux est en réalité un simple loader qui charge un second script hébergé sur un domaine enregistré et contrôlé par les attaquants. Ce script de second niveau, une fois chargé dans le navigateur de l'acheteur, établit une connexion WebSocket persistante avec le serveur de commande et contrôle (C2) des attaquants. Via ce canal bidirectionnel, le C2 transmet au navigateur un skimmer JavaScript personnalisé et adapté à l'apparence et à la structure spécifiques de la boutique victime. Cette personnalisation dynamique à la volée rend le skimmer plus efficace et significativement plus difficile à détecter par les outils de surveillance réseau ou les signatures d'antivirus génériques.

Le skimmer attend ensuite patiemment que l'utilisateur saisisse ses données de paiement dans le formulaire de checkout. Dès que l'acheteur remplit les champs de sa carte bancaire, le skimmer capture toutes les informations saisies : numéro complet de carte, date d'expiration, code de sécurité CVV/CVC, nom du titulaire, adresse de facturation, numéro de téléphone et adresse email. Ces données sont transmises en temps réel au C2, généralement chiffrées pour éviter leur détection par des sondes de surveillance du trafic réseau. L'acheteur complète sa transaction normalement sans se douter que ses données ont été copiées.

Les données ainsi volées sont immédiatement monnayables sur les marchés clandestins du dark web, où elles sont vendues en lots ou exploitées directement pour des achats frauduleux en ligne avant que les victimes ne constatent les débits non autorisés sur leurs relevés bancaires. Le délai entre le vol et la première utilisation frauduleuse est souvent inférieur à 24 heures selon les analyses de Wordfence.

FunnelKit a publié un correctif dans la version 3.15.0.3, disponible immédiatement via le dépôt officiel WordPress. La vulnérabilité n'a pas encore reçu d'identifiant CVE officiel au moment de la publication de cet article, bien que les chercheurs de WPScan l'aient référencée dans leur propre système de suivi des vulnérabilités WordPress. Les administrateurs de sites WooCommerce utilisant le plugin doivent mettre à jour sans délai. Au-delà de la mise à jour elle-même, il est impératif d'inspecter manuellement la section Settings > Checkout > External Scripts du plugin pour identifier et supprimer tout script non reconnu susceptible d'avoir été injecté avant l'application du correctif.

Pourquoi le web skimming reste l'une des menaces les plus destructrices pour le e-commerce

Les attaques de type web skimming représentent une menace directe pour les consommateurs et un risque de conformité majeur pour les marchands en ligne. Du point de vue du consommateur, le vol de données de carte bancaire lors d'un achat en ligne est une expérience particulièrement traumatisante : la victime n'a commis aucune erreur. Elle n'a cliqué sur aucun lien suspect, n'a téléchargé aucun logiciel malveillant, n'a répondu à aucun email de phishing. Elle a simplement effectué un achat sur ce qui semblait être un site e-commerce tout à fait légitime. Cette caractéristique perverse des attaques Magecart — infecter des sites légaux sans que propriétaires ni acheteurs ne s'en aperçoivent — les rend particulièrement insidieuses et difficiles à combattre.

Pour les marchands WooCommerce affectés, les conséquences dépassent largement le simple incident de sécurité. Le Règlement Général sur la Protection des Données (RGPD) impose une notification aux autorités de contrôle dans les 72 heures suivant la découverte d'une violation de données à caractère personnel. Les données de carte bancaire constituent des données financières particulièrement sensibles, et leur compromission déclenche également des obligations sous les standards PCI DSS (Payment Card Industry Data Security Standard). Les marchands non conformes aux exigences PCI DSS s'exposent à des amendes imposées par les circuits de paiement (Visa, Mastercard), voire à la perte de leur capacité d'accepter des paiements par carte, ce qui représente la mort commerciale pour un site e-commerce.

L'exploitation de plugins WordPress populaires comme vecteur d'attaque ciblant les données de paiement est un problème structurel qui ne se résoudra pas par un simple cycle de patch réactif. L'écosystème WordPress compte des dizaines de milliers de plugins développés par des équipes aux ressources et à la maturité sécurité très variables. Les composants critiques qui traitent directement des données de paiement — comme les plugins de checkout WooCommerce — devraient faire l'objet d'audits de sécurité réguliers et indépendants, et être soumis à des standards de certification analogues à ceux appliqués aux passerelles de paiement bancaires certifiées.

Les DSI et responsables e-commerce doivent intégrer dans leur programme de sécurité des contrôles spécifiques aux plateformes CMS. Cela comprend la mise en place d'une politique de mise à jour automatique ou au moins hebdomadaire de tous les plugins actifs, le monitoring de l'intégrité des fichiers et du code source des pages critiques — checkout, compte client, pages de saisie de données sensibles — et la vérification régulière des scripts tiers chargés via une politique de Content Security Policy (CSP) stricte avec reporting. Une CSP bien configurée aurait pu bloquer le chargement du script malveillant hébergé sur le domaine externe des attaquants, limitant significativement l'efficacité de cette attaque spécifique.

Ce qu'il faut retenir

• Mettre à jour immédiatement FunnelKit vers la version 3.15.0.3 et inspecter Settings > Checkout > External Scripts pour supprimer tout script inconnu potentiellement injecté.
• La technique d'attaque — skimmer masqué derrière un faux Google Tag Manager communiquant via WebSocket — illustre le niveau de sophistication opérationnelle des groupes Magecart actuels.
• Mettre en place une Content Security Policy (CSP) sur les pages de checkout WooCommerce est la mesure de défense en profondeur la plus efficace contre cette catégorie d'attaques, indépendamment des vulnérabilités de plugins.