Faille FunnelKit WooCommerce que vérifier sur ton checkout

FunnelKit Funnel Builder vient de prendre une alerte sérieuse côté WooCommerce. Si tu l’utilises pour construire tes tunnels de vente, tes pages de checkout, tes order bumps ou tes upsells, ce n’est pas une extension posée loin du paiement. Elle intervient dans la zone où ton client valide sa commande, laisse ses coordonnées et déclenche parfois des scripts marketing.

L’alerte publiée mi mai 2026 concerne Funnel Builder by FunnelKit dans toutes les versions avant 3.15.0.3. L’exploitation active a été observée sur des boutiques WooCommerce. Au moment de la rédaction, cette injection de scripts n’a pas encore de CVE officiel. Le plugin est utilisé par plus de 40 000 boutiques WooCommerce, ce qui donne à cette faille une portée assez large.

Le scénario est direct. Un endpoint de checkout public peut recevoir une requête non connectée. Dans les versions touchées, cette requête peut atteindre une méthode interne, puis modifier les réglages globaux du plugin. Le réglage qui pose problème ici est External Scripts, puisque ce champ peut ensuite injecter du JavaScript sur les pages de paiement.

Pourquoi cette faille FunnelKit doit être traitée vite

Une vulnérabilité sur un plugin de checkout n’a pas le même poids qu’un bug sur un bloc décoratif. FunnelKit peut se trouver sur la page où ton client saisit son adresse, son email, son téléphone et ses infos de paiement selon la configuration de ta passerelle. Un script ajouté à cet endroit peut lire beaucoup trop de choses.

Les attaquants ont profité de cette position. Ils ont injecté un faux script Google Tag Manager ou Google Analytics dans External Scripts. Dans une boutique qui utilise déjà plusieurs tags publicitaires, la ligne peut sembler banale au premier regard. C’est justement le piège. Le script charge ensuite un skimmer depuis analytics-reports[.]com et communique avec protect-wss[.]com.

Le but est clair. Capturer les numéros de carte, les CVV, les adresses de facturation et les données client saisies pendant le paiement. Même si ton prestataire de paiement limite l’exposition, tu dois vérifier le comportement réel du checkout, surtout si la carte est saisie dans la page WooCommerce via des champs intégrés.

Les versions FunnelKit à vérifier

Le repère est simple. Tout ce qui est antérieur à Funnel Builder 3.15.0.3 doit être corrigé. La version 3.15.0.2 réglait déjà une injection SQL distincte publiée fin avril 2026, mais elle ne suffit pas pour cette alerte liée au skimmer. La version à viser est donc 3.15.0.3 ou une version plus récente.

Ce que fait l’attaque sur le checkout WooCommerce

Le point faible se situe autour d’un endpoint public de checkout. Dans les anciennes versions, une requête pouvait choisir un type de méthode interne à exécuter sans contrôle de permission suffisant. Une méthode accessible permettait ensuite d’écrire dans les réglages globaux du plugin.

Une fois le script ajouté dans External Scripts, il pouvait être imprimé sur les pages de checkout FunnelKit. L’attaquant n’avait pas besoin d’obtenir un compte admin WordPress pour arriver à ce résultat si le site utilisait une version vulnérable.

Le code observé cherchait à ressembler à un loader analytics. Il appelait analytics-reports[.]com, puis ouvrait une communication avec protect-wss[.]com pour récupérer un skimmer adapté à la boutique ciblée. La page peut donc paraître normale côté client, pendant qu’un script non prévu surveille les champs du paiement.

Le contrôle à faire dans WordPress

Commence par la base. Ouvre Extensions dans WordPress, vérifie FunnelKit Funnel Builder, puis mets à jour vers 3.15.0.3 ou plus récent. Une fois la mise à jour faite, ne ferme pas l’admin trop vite.

Va dans les réglages FunnelKit, puis Checkout, puis External Scripts. Tu dois reconnaître chaque ligne. Un tag marketing légitime doit avoir un propriétaire clair, une raison claire et une date d’ajout cohérente. Si personne ne sait pourquoi il est là, tu ne le gardes pas par confort.

Si tu trouves un script encodé, un domaine inconnu, un fichier nommé pour ressembler à jQuery, analytics ou reports, garde une copie avant retrait. Note l’heure, l’URL, le contenu et le contexte. Retire ensuite le script, vide tous les caches, puis repasse le site en vérification.

Pense aussi aux autres emplacements capables d’injecter du code. Thème, Google Tag Manager, WooCommerce, constructeur de pages, extension de tracking, outil de consentement, header global ou plugin SEO. Une attaque repérée dans FunnelKit doit pousser à relire tout ce qui peut ajouter du JavaScript sur le checkout.

Les traces à chercher dans les logs

Regarde les accès autour des dates de publication de l’alerte, puis élargis si ton site avait une version touchée depuis plusieurs jours. Les requêtes suspectes peuvent viser des endpoints FunnelKit ou des routes WooCommerce liées au checkout. Le signal utile n’est pas forcément un gros volume. Une seule requête réussie peut suffire à modifier le réglage.

Surveille les appels POST inhabituels, les user agents vides, les IP qui ne visitent presque rien sauf le checkout, les requêtes suivies d’une modification de réglage, puis les chargements externes sur les pages de paiement. Si ton hébergeur garde les journaux HTTP, compare les heures avec les changements visibles dans l’administration WordPress.

Si tu utilises un WAF, regarde les blocages et les requêtes autorisées. Un site peut avoir reçu des tentatives avant et après la mise à jour. Ce détail aide à savoir si tu as seulement corrigé à temps ou si tu dois passer en nettoyage complet.

Pourquoi le risque SEO arrive aussi derrière

Le premier risque reste le vol de données au paiement. C’est lui qui doit dicter l’ordre des actions. Mais une boutique compromise peut aussi prendre un coup côté SEO. Google peut détecter des scripts malveillants, afficher un avertissement de navigation, freiner l’indexation ou associer le domaine à une boutique dangereuse.

Pour une boutique qui dépend du trafic organique, la perte peut arriver vite. Même après retrait du script, il peut rester des effets visibles dans Search Console, dans le crawl ou dans la confiance accordée au domaine. C’est pour ça que le nettoyage ne doit pas s’arrêter au plugin.

Si tu dois traiter une boutique touchée, vérifie aussi les pages indexées, les redirections, les fichiers modifiés et les comptes administrateurs. Leclerc Web a déjà détaillé le piratage par mots clés japonais, les permissions CHMOD WordPress et le fichier index.php piraté. Ces contrôles se complètent bien après une attaque sur un site marchand.

Le plan de correction sans perdre une journée

Commence par couper le risque actif. Mets FunnelKit à jour. Retire tout script inconnu dans External Scripts. Vide le cache serveur, le cache WordPress, le cache CDN et les caches de pages liées au checkout. Ouvre ensuite la page de paiement depuis une session non connectée, idéalement en navigation privée, puis regarde les scripts chargés.

Tu dois retrouver uniquement les domaines attendus. Ton domaine, ta passerelle de paiement, ton outil de consentement, tes tags marketing validés et les services que tu utilises vraiment. Si analytics-reports[.]com ou protect-wss[.]com apparaît encore, le nettoyage n’est pas terminé.

Vérifie ensuite les commandes récentes. Si la passerelle redirige entièrement vers un prestataire externe et que les numéros de carte ne passent jamais dans la page WooCommerce, l’exposition peut être plus limitée. Si la carte est saisie dans le checkout, même via champs intégrés, traite les commandes récentes avec plus de prudence et contacte ton prestataire de paiement si le doute tient la route.

Le lien avec les autres alertes WordPress récentes

FunnelKit arrive après plusieurs alertes WordPress sur des plugins très utilisés ou sur des briques proches du paiement, des emails et des builders. Si tu as lu notre point sur Gravity SMTP CVE-2026-4020, tu as déjà vu le même réflexe. On corrige, puis on vérifie ce que la faille aurait pu exposer.

Même logique avec Avada Builder, où une version corrigée ne remplace pas le contrôle des fichiers, de la base et des comptes. Sur WooCommerce, paiement, email, tracking, tunnel de vente, cache, SEO et formulaires travaillent ensemble. Quand une extension sensible prend une faille publique exploitée, le bon rythme consiste à relire tout le parcours d’achat.

Mon avis franc

Cette faille FunnelKit mérite une vraie priorité parce qu’elle touche la page la plus sensible d’une boutique. Pas de compte requis, injection possible dans les réglages, exécution sur le checkout, camouflage en tag analytics et exploitation déjà observée. Le bouton Mettre à jour règle la porte d’entrée, mais il ne prouve pas que ton checkout est propre.

Si tu utilises Funnel Builder sur WooCommerce, fais le contrôle maintenant. Version 3.15.0.3 ou plus récent, External Scripts propre, logs relus, checkout testé en navigation privée, cache vidé. Si un script suspect était présent, passe en nettoyage complet et fais remonter l’information côté paiement. Une boutique saine, c’est une boutique où tu sais exactement quel code tourne au moment de payer.