Vous avez entendu parler des vols de données bancaires sur PrestaShop. Par acquit de conscience, vous ouvrez votre boutique, vous allez jusqu’au tunnel de commande, vous inspectez la page de paiement. Rien d’anormal. Le formulaire est celui de votre passerelle habituelle. Vous refermez l’onglet, rassuré.
Ce test ne prouve rien. C’est même exactement le comportement sur lequel comptent les attaquants.
La vague de skimmers qui frappe les boutiques PrestaShop depuis janvier 2026 a une caractéristique qui change tout : le code malveillant se désactive quand un administrateur est connecté au back-office. Il vous reconnaît, il se tait, et il reprend son travail dès que vous partez.
Ce que fait ce malware
Le principe général est connu sous le nom de Magecart : du JavaScript injecté dans les pages de paiement, qui capture les données de carte bancaire au moment où le client les saisit, puis les envoie vers un serveur tiers.
Ce qui distingue la campagne de 2026, ce sont ses mécanismes d’évasion. D’après les analyses publiées, le code contrôle la présence d’un cookie de session administrateur avant de s’activer. Certaines variantes vont plus loin en ne s’affichant qu’une visite sur deux, ce qui rend le comportement irrégulier et brouille les tentatives de reproduction.
Les techniques observées varient selon les variantes : capture des frappes dans le formulaire de paiement légitime, ou remplacement du bouton de paiement par un faux qui redirige vers un formulaire contrefait. Dans les deux cas, la destination finale est un domaine tiers dont le nom imite souvent celui d’un CDN connu — de quoi passer inaperçu dans une liste de requêtes réseau.
La conséquence est brutale : une boutique compromise devient un distributeur de numéros de cartes, et peut le rester des semaines sans que le commerçant s’en aperçoive. PrestaShop a d’ailleurs alerté les marchands par e-mail en février 2026 au sujet d’un script de vol de données de paiement.
Pourquoi votre vérification ne vaut rien
C’est le point que je veux marteler, parce qu’il piège des commerçants sérieux et des développeurs compétents.
Quand vous testez votre propre boutique, vous êtes dans le pire état possible pour détecter ce malware : session administrateur ouverte, cookies chargés, navigateur habituel, adresse IP connue. Le skimmer coche toutes les cases pour rester silencieux.
Vous obtenez donc un résultat négatif — et vous en tirez une conclusion positive. L’erreur de logique est là : l’absence de preuve d’infection n’est pas une preuve d’absence d’infection. Ce n’est pas une nuance philosophique, c’est la différence entre une boutique saine et une boutique qui saigne les cartes de ses clients depuis deux mois.
Pire : ce faux négatif vous rassure durablement. Ayant vérifié, vous ne revérifierez pas avant longtemps.
Comment vérifier pour de vrai
Puisque le malware se cache de l’administrateur, la règle est simple : testez comme un client, pas comme un gérant.
Sortez de votre session. Fenêtre de navigation privée, ou mieux, un autre navigateur où vous n’avez jamais ouvert le back-office. Ne vous contentez pas de vous déconnecter : purgez les cookies du domaine.
Changez de réseau. Testez depuis votre connexion mobile, en coupant le Wi-Fi. Certaines variantes filtrent aussi sur l’adresse IP.
Recommencez plusieurs fois. Si l’affichage est intermittent, un seul test peut tomber sur une visite « propre ». Répétez le parcours cinq à dix fois, à quelques minutes d’intervalle.
Allez jusqu’au bout du tunnel. Le code ne se déclenche souvent que sur la page de paiement finale, avec un panier réel. Une visite de la page d’accueil n’active rien.
Inspectez les requêtes réseau. Ouvrez les outils de développement, onglet Réseau, et regardez vers quels domaines part le trafic pendant la saisie du formulaire. Un domaine qui ressemble à un CDN sans en être un — variation orthographique, extension inhabituelle — est un signal fort. Comparez avec les domaines légitimes de votre passerelle de paiement.
Vérifiez la destination du bouton de paiement. Le bouton doit pointer vers votre prestataire déclaré, pas vers une URL intermédiaire.
Demandez à quelqu’un d’autre. Un proche, sur son propre matériel et sa propre connexion, qui n’a jamais visité votre back-office. C’est le test le plus proche des conditions réelles d’un client.
Le réflexe qui manque : chercher côté serveur
Tout ce qui précède reste une observation depuis l’extérieur. Pour savoir si le code est présent, il faut regarder là où il est stocké.
Le JavaScript malveillant ne vit pas forcément dans un fichier. Sur PrestaShop, il est très souvent injecté dans la base de données — dans les champs de code personnalisé de ps_configuration, dans une page CMS, ou dans un module désactivé mais toujours accroché à un hook du front-office. C’est ce qui explique qu’une boutique « nettoyée » se retrouve infectée à nouveau quelques jours plus tard : les fichiers ont été purgés, la charge utile est restée en base.
J’ai détaillé les emplacements précis et les requêtes SQL pour les inspecter dans un article dédié : pourquoi votre PrestaShop se ré-infecte après nettoyage. Si vous suspectez quoi que ce soit, commencez par là.
Attention en cherchant : le code est presque toujours obfusqué. Vous ne trouverez pas d’URL en clair, mais des appels à atob() sur du base64, ou des tableaux de nombres passés à String.fromCharCode(). Retenez le principe — du code encodé dans un champ de configuration n’a aucune raison d’être là. Aucun outil légitime n’a besoin de dissimuler son adresse.
Détecter un skimmer qui se cache
Genisoft Security Scanner dé-obfusque les atob() et les tableaux String.fromCharCode pour révéler le domaine d'exfiltration dissimulé, et repère les gardes d'évasion back-office. Il inspecte les fichiers et la base de données. 100 % lecture seule.
Si vous découvrez une infection
L’ordre des opérations compte, et il n’est pas intuitif.
Sauvegardez d’abord l’état compromis — fichiers et base — hors du serveur. C’est votre preuve, et votre filet si vous cassez quelque chose. Coupez ensuite tous les accès : mots de passe employés, base, FTP et SSH, et surtout supprimez les comptes administrateurs que vous ne reconnaissez pas. Neutralisez la persistance en base avant de toucher aux fichiers, sinon le nettoyage sera annulé dans les heures qui suivent.
Deux obligations que beaucoup ignorent, et qui ne sont pas optionnelles quand des données bancaires sont en jeu : prévenez votre prestataire de paiement, qui a des procédures pour ce cas, et évaluez votre obligation de notification RGPD. Une fuite de données bancaires de clients est une violation de données personnelles ; selon la gravité, elle doit être notifiée à la CNIL sous 72 heures, et parfois aux clients concernés. En cas de doute sur l’étendue de la compromission, faites-vous accompagner — c’est le moment où une erreur d’appréciation coûte le plus cher.
Ce qui aurait évité ça
Les vecteurs d’entrée de cette campagne ne sont pas exotiques. Ce sont, comme presque toujours, des modules tiers laissés sans mise à jour et des accès administrateur trop faibles. Plusieurs failles activement exploitées ces derniers mois concernaient des modules tiers, pas le cœur de PrestaShop.
Mettre à jour vite, désinstaller — et pas seulement désactiver — ce qui ne sert plus, activer l’authentification à deux facteurs sur le back-office, et surveiller régulièrement ce qui tourne réellement sur la boutique. Rien de spectaculaire, mais c’est ce qui sépare une boutique visitée d’une boutique compromise.
Et surtout, retenez le point de départ : le fait que vous ne voyiez rien ne signifie rien. Ce malware a été conçu précisément pour ça.
Pour aller plus loin :
- Pourquoi votre PrestaShop se ré-infecte après nettoyage
- Faille de sécurité majeure sur les sites PrestaShop
- Sécurité PrestaShop : IA locale ou WAF cloud ?
