Des pirates détournent le script d’analyse Plausible de Convertr pour siphonner les cartes bancaires au paiement
Le 24 octobre 2026, un groupe de skimming a modifié le script d’analyse Plausible hébergé par la plateforme e-commerce brésilienne Convertr pour voler les données de carte pendant le paiement, en exploitant peut-être une faille de Plausible Community Edition. Tout acheteur passé par une caisse « checkout.convertr » depuis cette date doit bloquer sa carte, et les e-commerçants doivent traiter leurs scripts d’analyse tiers comme une surface d’attaque.
24 octobre 2026. L’entreprise de sécurité Sansec identifie une campagne de skimming de cartes : le script d’analyse Plausible hébergé par Convertr, plateforme e-commerce brésilienne, a été modifié pour voler les données de paiement pendant le checkout. 26 octobre 2026. Les attaquants poussent une version raffinée du skimmer, ciblant cette fois les noms exacts des champs de l’API de paiement de Convertr. 27 octobre 2026. Sansec confirme que Convertr a retiré le skimmer et mis à jour Plausible vers une version corrigée. Le point qui compte : pendant au moins deux jours, toutes les caisses des enseignes hébergées par Convertr — des dizaines de marques de mode majeures au Brésil — chargeaient silencieusement un script de vol de cartes livré par la chaîne d’analyse elle-même.
Une chaîne d’approvisionnement attaquée là où personne ne regarde : le script d’analyse
Le mécanisme est un classique du Magecart, mais son point d’entrée est plus vicieux qu’un piratage de boutique. Les attaquants n’ont pas compromis le code des marchands. Ils ont modifié le fichier du tracker Plausible hébergé sur un serveur auto-géré opéré par Convertr — c’est-à-dire le script d’analyse que chaque boutique de la plateforme charge déjà sur ses pages de paiement, en toute confiance.
Ce script légitime est injecté dans toutes les caisses des marchands utilisant la plateforme. En le détournant à la source, un seul point d’infiltration suffit à toucher des dizaines d’enseignes à la fois : la définition même d’une attaque de supply chain. Sansec l’attribue à un gang brésilien actif depuis au moins juillet 2024, spécialisé dans l’infection de boutiques Magento, OpenCart et WooCommerce.
Un point d’accès initial probable, pas encore confirmé
Sansec suspecte que les attaquants ont exploité une vulnérabilité d’exécution de commande non authentifiée dans l’installation de Plausible Community Edition de Convertr — une version obsolète — pour obtenir l’accès initial. L’entreprise cite la CVE-2026-8467, tout en précisant que ce vecteur n’est pas confirmé.
La nuance compte. Qu’il s’agisse de cette CVE précise ou d’un autre chemin, la leçon est la même : un script d’analyse auto-hébergé et non mis à jour devient un point d’entrée vers l’ensemble des boutiques qui l’embarquent. On a trop longtemps traité Plausible, Matomo ou Umami comme des dépendances « anodines » parce qu’elles ne touchent pas directement au paiement — c’est précisément parce qu’elles sont chargées sur la page de paiement qu’elles sont dangereuses.
Ce que volait le skimmer
Le skimmer injecté était configuré pour capturer six champs sur les pages de checkout : le numéro de carte, la date d’expiration, le code CVV, le nom du titulaire, et le CPF — le numéro d’identification fiscale brésilien, l’équivalent d’un identifiant personnel dont la revente aggrave le préjudice.
La progression de l’attaque est documentée par Sansec. Les premières versions utilisaient des motifs génériques de champs de paiement. À partir du 26 octobre 2026, les attaquants ont poussé une version plus raffinée qui ciblait les noms exacts des champs de l’API de paiement de Convertr. Ce n’est pas un détail technique : c’est le signe d’un attaquant qui adapte son outil à la cible, et donc d’une campagne qui se professionnalise.
Que faire si vous avez payé sur une caisse Convertr
Le conseil de Sansec est sans ambiguïté. Toute personne ayant payé par carte sur une boutique dont l’adresse de checkout contenait la chaîne checkout.convertr depuis le 24 octobre 2026 doit contacter sa banque immédiatement et demander le blocage de sa carte.
Deux subtilités rendent la remédiation moins simple qu’elle n’y paraît. D’abord, Convertr a annoncé notifier les marchands et les prestataires de paiement concernés — mais l’ampleur de la base de clients touchés n’est pas encore publique. Ensuite, Sansec avertit que le cache du navigateur peut maintenir le script malveillant actif sur les sites impactés jusqu’à 24 heures après le nettoyage : les acheteurs doivent vider leur cache avant de passer une nouvelle commande, même une fois la menace éliminée.
Pour les acheteurs, la protection la plus robuste reste la carte virtuelle jetable, qui expire immédiatement après une transaction. C’est la seule parade qui neutralise le skimming à la source, quel que soit l’état du script chargé.
Pourquoi les scripts d’analyse sont la nouvelle porte du Magecart
Cette attaque n’est pas un accident isolé. Depuis plusieurs années, le Magecart — le terme générique pour le skimming de cartes via du JavaScript injecté — a migré des boutiques directement compromises vers les scripts tiers chargés par ces boutiques. Un pixel publicitaire, un widget de chat, un script d’A/B testing ou un outil d’analyse : chacun est un petit programme exécuté avec les privilèges de la page de paiement, et chacun peut être modifié en amont sans que le marchand ne touche à son propre code.
Le régulateur a intégré cette réalité. La version 4.0 de PCI DSS impose, via les exigences 6.4.3 et 11.6.1, que les entités qui gèrent des pages de paiement inventorient leurs scripts et détectent les modifications non autorisées — typiquement en comparant des empreintes d’intégrité. Une instance Plausible auto-hébergée et non surveillée est précisément le scénario que ces exigences veulent rendre impossible : un script que l’on charge partout, que l’on met rarement à jour, et dont personne ne vérifie le contenu.
Ce qu’il faut faire côté e-commerce
Pour les équipes qui exploitent une boutique en ligne, cette affaire impose trois contrôles.
Inventoriez vos scripts tiers. Listez chaque script chargé sur la page de paiement — analyse, chat, A/B testing, pixel publicitaire. Chacun est un vecteur d’injection potentiel, pas un confort sans risque.
Mettez à jour vos instances auto-hébergées. Une Plausible Community Edition obsolète est la cause probable de la compromission. Appliquez les correctifs comme vous le feriez pour n’importe quel logiciel exposé, avec la même priorité.
Durcissez l’intégrité. Utilisez l’intégrité de sous-ressource (SRI) quand le script est servi en tiers, surveillez les modifications de vos fichiers d’analyse, et restreignez qui peut écrire sur le serveur qui les héberge. Un fichier de tracker qui change sans raison est un signal d’alarme.
Verdict
Si vous exploitez une boutique en ligne, traitez vos scripts d’analyse comme une dépendance de supply chain à part entière : version à jour, accès en écriture restreint, surveillance des changements, et SRI sur les scripts tiers. Le coût est faible, la surface couverte est celle de toute votre clientèle au moment le plus sensible. Si vous êtes un acheteur ayant payé sur une caisse « checkout.convertr » depuis le 24 octobre 2026, bloquez votre carte sans attendre et privilégiez désormais les cartes virtuelles jetables. La leçon de Convertr dépasse le Brésil : le Magecart n’a pas disparu, il a seulement changé de porte d’entrée — et il frappe maintenant à celle que personne ne verrouille, le script d’analyse chargé sur la page de paiement.