FunnelKit Funnel Builder : une faille laissait voler les numéros de carte bancaire de vos clients
FunnelKit Funnel Builder est un plugin WooCommerce installé sur plus de 40 000 boutiques - il gère les tunnels de vente, les pages de checkout personnalisées et les upsells post-achat. Mi-mai 2026, la société Sansec a confirmé une exploitation active d'une faille dans ce plugin : un endpoint de checkout accessible à tous, sans aucune vérification d'identité, permettait d'injecter un script de vol de cartes bancaires directement dans les pages de paiement. Vos clients réglaient leur commande, et leurs données partaient en parallèle vers un serveur contrôlé par des attaquants. Sans veille de sécurité active, ce type d'injection reste invisible pendant des semaines.
Sommaire
- FunnelKit sur 40 000 boutiques WooCommerce
- La faille : un endpoint de checkout exposé sans contrôle d'accès
- Le skimmer WebSocket : vol de données de paiement en temps réel
- Les indicateurs de compromission à vérifier
- Un historique de failles qui interroge
- Versions concernées et correctif
- Ce qu'il faut faire maintenant
- FAQ
FunnelKit sur 40 000 boutiques WooCommerce
FunnelKit - anciennement WooFunnels - est un éditeur spécialisé dans l'optimisation des conversions WooCommerce. Son plugin phare, Funnel Builder by FunnelKit, permet de personnaliser les pages de checkout, d'ajouter des upsells post-achat, de créer des entonnoirs de vente complets et de remplacer la page de paiement par défaut de WooCommerce par une version optimisée. C'est un outil légitime, populaire, avec plus de 40 000 installations actives selon WordPress.org.
Ce qui rend ce plugin particulièrement attractif pour un attaquant, c'est son positionnement exact dans le parcours d'achat. Funnel Builder touche directement les pages où les clients saisissent leurs données bancaires. Compromettre ce plugin, c'est se placer en intermédiaire entre votre client et sa carte de crédit. C'est Sansec, spécialiste néerlandais de la sécurité e-commerce, qui a identifié et publié l'analyse de l'exploitation - relayée ensuite par BleepingComputer.
La faille : un endpoint de checkout exposé sans contrôle d'accès
Le mécanisme est simple. FunnelKit expose un endpoint de checkout accessible publiquement - il fait partie du fonctionnement normal du plugin, utilisé pour les interactions entre les pages de paiement et le serveur. Ce qui ne l'est pas, c'est qu'il acceptait des requêtes de modification des paramètres globaux du plugin sans vérifier l'identité de l'appelant.
N'importe qui pouvait envoyer une requête POST à cet endpoint pour modifier le champ External Scripts dans les paramètres du checkout. Ce champ est prévu pour charger des scripts tiers légitimes - Google Analytics, Facebook Pixel, outils de tracking marketing. Il suffit d'y injecter une ligne malveillante pour que ce script s'exécute sur toutes les pages de checkout du site, à chaque commande passée par un client.
Techniquement, il s'agit d'une faille d'autorisation manquante : l'endpoint existait, les fonctionnalités qu'il exposait existaient, mais la vérification du droit d'y accéder avait été omise. Pas de désérialisation PHP, pas d'upload arbitraire - juste une porte laissée ouverte dans un endroit où elle n'aurait pas dû l'être. C'est d'ailleurs la première catégorie de vulnérabilité web référencée par l'OWASP Top 10 : les contrôles d'accès défaillants. La plus banale, et souvent la plus dévastatrice.
Le skimmer WebSocket : vol de données de paiement en temps réel
Le script injecté par les attaquants ne vole pas les données directement depuis la base de données. Il est plus discret que ça.
Le payload se présente comme un faux script Google Tag Manager ou Google Analytics, hébergé à l'adresse analytics-reports[.]com/wss/jquery-lib.js. Nom de fichier crédible, domaine qui ressemble à quelque chose de connu - Google Analytics, jQuery, rien d'alarmant en surface pour quelqu'un qui inspecterait les External Scripts sans se méfier.
Une fois chargé sur la page de checkout, ce script ouvre une connexion WebSocket vers wss://protect-wss[.]com/ws, un serveur contrôlé par les attaquants. Le protocole WebSocket est un canal de communication bidirectionnel persistant : contrairement à une requête HTTP classique, il maintient une connexion ouverte et transmet les données en continu. Le serveur distant reçoit en temps réel les données saisies dans le formulaire de paiement : numéro de carte, date d'expiration, CVV, nom du porteur, adresse de facturation.
Tout ça se passe pendant que votre client voit une page de paiement normale. Votre logo, votre design, les icônes de paiement sécurisé. Aucun signe visible.
C'est ce que les chercheurs appellent un skimmer de formulaire - une évolution des skimmers physiques qu'on trouve sur les distributeurs automatiques, adaptée aux formulaires web. La particularité du vecteur WebSocket est sa discrétion : les données ne quittent pas le site via une requête HTTP visible dans les logs standards. La connexion est chiffrée (wss://) et ressemble de l'extérieur à une connexion analytics ordinaire. Dans les audits post-compromission que nous menons, ce type de payload est parmi les plus difficiles à détecter rétrospectivement.
Les indicateurs de compromission à vérifier
analytics-reports[.]com/wss/jquery-lib.js dans FunnelKit → Settings → Checkout → External Scriptswss://protect-wss[.]com/ws dans les logs serveurUn historique de failles qui interroge
Cette exploitation active n'est pas un accident isolé. Depuis 2023, la base de données Patchstack recense 13 vulnérabilités documentées sur Funnel Builder by FunnelKit, dont plusieurs particulièrement sérieuses :
- Injection SQL non authentifiée (<= 3.13.1.5) - décembre 2025
- Injection SQL (<= 3.15.0.1) - avril 2026
- Escalade de privilèges (<= 3.11.0.2) - août 2025
- Local File Inclusion (<= 3.11.1 et <= 3.9.0) - août et février 2025
- Cross-Site Scripting réfléchi (< 3.12.0.1) - novembre 2025
Deux injections SQL, dont une non authentifiée, en moins de six mois. Une escalade de privilèges. Deux inclusions de fichiers locaux. Et maintenant un endpoint de checkout ouvert à tous pour injecter des skimmers. Ce n'est pas un plugin qui a eu un bug - c'est un plugin avec des lacunes récurrentes dans la gestion des droits d'accès, version après version.
Ces failles sont corrigées dans les versions correspondantes - la mise à jour résout le problème. Mais un plugin qui touche directement les pages de paiement, avec ce profil, mérite une surveillance bien plus serrée que la moyenne. Les correctifs de sécurité doivent être appliqués dans les heures suivant leur publication, pas dans les semaines.
Nous avions détaillé les risques des plugins à l'historique problématique dans un guide dédié. FunnelKit n'est pas abandonné - mais il illustre bien pourquoi l'historique de sécurité d'un plugin est un critère de choix, pas une anecdote.
Versions concernées et correctif
| Plugin | Versions vulnérables | Version corrigée | Type de faille |
|---|---|---|---|
| Funnel Builder by FunnelKit | < 3.15.0.3 | 3.15.0.3 (14 mai 2026) | Injection de script non authentifiée via endpoint checkout |
Ce qu'il faut faire maintenant
Tableau de bord → Extensions → Mises à jour disponibles. Appliquez la mise à jour vers la version 3.15.0.3 (publiée le 14 mai 2026). Cette version ferme l'endpoint de checkout ouvert qui permettait l'injection de scripts sans authentification.
Allez dans FunnelKit → Settings → Checkout → External Scripts. Supprimez immédiatement tout script que vous n'avez pas vous-même ajouté - en particulier analytics-reports[.]com/wss/jquery-lib.js ou tout autre script d'origine inconnue. La mise à jour ne supprime pas les scripts déjà injectés. Cette vérification manuelle est indispensable.
Cherchez dans vos logs Apache ou Nginx des requêtes POST vers les endpoints FunnelKit sans authentification, et des connexions sortantes vers protect-wss[.]com. Si vous identifiez des requêtes suspectes, notez les plages horaires - elles permettront d'estimer quelles transactions ont pu être exposées.
Si le script de skimming était présent et que des commandes ont été passées pendant cette période, les données de carte bancaire des clients concernés peuvent avoir été compromises. Informez votre processeur de paiement (Stripe, PayPal, etc.) et notifiez la CNIL sous 72 heures conformément au RGPD. Nos experts peuvent vous accompagner dans cette démarche.
Utilisez Wordfence ou Sucuri pour scanner l'ensemble des fichiers. La présence d'un skimmer peut accompagner d'autres modifications malveillantes. Si le scan révèle des fichiers suspects ou des backdoors, faites appel à un expert WordPress avant de reprendre les transactions.
Si vous gérez une boutique WooCommerce et que surveiller chaque bulletin de sécurité plugin n'entre pas dans votre journée, c'est exactement ce que couvre un contrat de maintenance WordPress : application des correctifs critiques dans les heures suivant leur publication, vérification des configurations sensibles et alerte immédiate dès qu'un indicateur suspect apparaît.
FAQ - Faille FunnelKit Funnel Builder
Mon site utilise FunnelKit mais n'a pas de boutique active - suis-je quand même concerné ?
Le risque de vol de données de paiement concerne directement les boutiques avec un tunnel d'achat actif. Mais l'endpoint vulnérable est présent dès que le plugin est actif, même sans boutique opérationnelle. Un attaquant peut injecter un script préparatoire en attendant que la boutique soit mise en ligne. La mise à jour s'impose dans tous les cas.
La mise à jour vers 3.15.0.3 nettoie-t-elle les scripts déjà injectés ?
Non. La mise à jour ferme l'endpoint qui permettait l'injection, mais elle ne supprime pas ce qui a déjà été injecté. Après avoir mis à jour le plugin, vous devez vérifier manuellement FunnelKit → Settings → Checkout → External Scripts et supprimer tout script inconnu. Les deux étapes sont indispensables.
Qu'est-ce qu'un skimmer WebSocket et pourquoi est-il difficile à détecter ?
Un skimmer WebSocket est un script malveillant qui ouvre une connexion persistante vers un serveur externe et transmet en temps réel les données saisies dans les formulaires. Il est difficile à détecter parce qu'il ne modifie aucun fichier PHP du site - il est logé dans la configuration du plugin. Les scans de fichiers classiques ne le voient pas. Son nom (jquery-lib.js) est conçu pour passer pour un script jQuery légitime.
Dois-je notifier mes clients et les autorités si mon site a été compromis ?
Oui, si des données de carte bancaire ont pu être interceptées. Le RGPD impose de notifier la CNIL sous 72 heures en cas de violation de données personnelles, et une notification individuelle des clients concernés peut être obligatoire selon l'étendue de la compromission. Informez aussi votre processeur de paiement (Stripe, PayPal, etc.) qui peut prendre des mesures préventives sur les cartes exposées. Ne tardez pas - les délais légaux sont stricts.
FunnelKit est-il fiable malgré son historique de failles ?
FunnelKit est un produit fonctionnel utilisé par des milliers de boutiques. Mais 13 vulnérabilités documentées depuis 2023 - dont deux injections SQL non authentifiées en six mois - indique des lacunes récurrentes dans les contrôles d'accès. Si vous continuez à l'utiliser, les mises à jour de sécurité doivent être appliquées dans les heures suivant leur publication, pas dans les semaines. Un plugin en contact direct avec les pages de paiement ne tolère pas la négligence.
Un plugin de checkout compromis, ce n'est pas comme les autres
La plupart des failles WordPress permettent à un attaquant de prendre le contrôle de votre site - c'est grave, ça se répare. Une faille de skimming sur un checkout WooCommerce, c'est vos clients qui se font voler leurs données bancaires pendant qu'ils font confiance à votre boutique. La compromission ne touche pas seulement votre infrastructure - elle touche des tiers dont vous êtes légalement responsable de la sécurité des données de paiement.
La banalité du vecteur, c'est ce qui frappe. Pas d'exploit sophistiqué, pas de faille obscure. Un champ de configuration modifiable sans mot de passe. Les bots qui automatisent ce type d'attaque n'ont pas besoin d'être intelligents - ils scannent, trouvent l'endpoint ouvert, injectent. Sur des milliers de sites en parallèle.
La faille Burst Statistics reposait sur le même principe - des endpoints sans vérification d'identité. La double faille Breeze Cache et User Registration aussi. Ce n'est pas une coïncidence : les contrôles d'accès manquants sont la faille la plus banale, la plus corrigible, et pourtant la plus régulièrement oubliée dans le code des plugins WordPress. La question n'est pas de savoir si votre prochain plugin sera vulnérable. C'est de savoir combien de temps s'écoule entre la publication du correctif et son application sur votre site.