Boutique PrestaShop piratée

Votre boutique est peut-être en train de vendre les coordonnées bancaires de vos clients pendant que vous lisez cet article.

Ce n’est pas une figure de style. Le skimmer qui circule depuis début 2026 sur les boutiques PrestaShop a une particularité redoutable : il se désactive quand un administrateur est connecté au back-office. Vous naviguez sur votre boutique, vous passez une commande test, tout semble normal. Vos clients, eux, voient un faux formulaire de paiement.

Mais d’abord, il faut comprendre ce qui se passe — et pourquoi février 2026 a changé la donne pour tous les marchands PrestaShop.

12 février 2026, 14h37 — le jour où tout a basculé

Pour comprendre pourquoi cet article existe, il faut remonter à un mercredi après-midi de février.

Ce jour-là, les boîtes de réception de centaines de milliers de marchands PrestaShop se sont remplies d’un email au ton inhabituel. Objet : « Alerte de sécurité — Vérification recommandée de vos boutiques. » Dedans, une phrase qui a glacé ceux qui l’ont lue : « vol des informations de paiement de certains de vos clients ».

La plupart des marchands ont cru à du phishing. L’email ressemblait exactement à ce genre de piège. Sauf que non.

Quelques jours plus tôt, Clément Domingo (@SaxX), chercheur en cybersécurité français, avait déjà identifié la menace et publié une analyse technique sur les réseaux sociaux. Le mécanisme qu’il a décrit est redoutable : un script injecté dans le fichier head.tpl du thème remplace les boutons de paiement légitimes par des copies visuellement identiques. Le client clique, tombe sur un faux formulaire, entre ses données CB. Le formulaire affiche une erreur. Le client croit s’être trompé, recommence — cette fois sur le vrai formulaire. La commande passe. Le marchand encaisse. Le client reçoit sa confirmation.

Tout semble normal. Sauf que les données bancaires viennent d’être copiées et envoyées à un serveur contrôlé par des pirates.

C’est ce qu’on appelle le « double-tap skimming ». Et c’est diaboliquement efficace.

Quelques chiffres

– Plus de 50 000 boutiques PrestaShop sont actives en France. 300 000 dans le monde. C’est le CMS e-commerce le plus déployé en France. Et c’est exactement ce qui en fait la cible n°1 des groupes de cybercriminels spécialisés, les fameux « Magecart ».
– En 2024, un site piraté sur trois dans le monde était un e-commerce.
– En 2022, 40% des attaques par rançongiciel traitées par l’ANSSI visaient des TPE, PME et ETI.

Dix jours plus tard, ça a pris une dimension qu’aucun marchand n’avait anticipée : le Crédit Agricole Charente-Maritime Deux-Sèvres a envoyé des courriers recommandés à ses clients e-commerçants utilisant PrestaShop. Le courrier demandait explicitement de contacter leur mainteneur pour vérifier que le site n’était pas compromis.

La question que personne n’a posée : combien de marchands ont reçu cet email de PrestaShop et l’ont ignoré parce qu’il ressemblait à du spam ? Et combien de boutiques sont encore infectées aujourd’hui ?

Les 3 types de piratage sur PrestaShop

Tous les piratages ne se ressemblent pas. Et la réaction à avoir ne doit pas être la même selon la méthode. Voici les trois cas qu’on rencontre sur PrestaShop.

Le défacement et la redirection — visible, stressant, mais le moins grave

Votre boutique redirige vers un casino en ligne, un site de contrefaçon, ou affiche du contenu en japonais dans les titres de pages. Parfois c’est un peu plus subtil : des produits modifiés avec des titres incohérents, des prix passés à 0 € ou 1 €, des bannières remplacées par du contenu publicitaire pour adulte.

C’est le signe d’un un malware qui infecte la balise <title> de votre site. Résultat : votre boutique est indexée dans Google avec du contenu malveillant. Google peut blacklister votre domaine en quelques heures — message rouge « Site dangereux » pour tous vos visiteurs, SEO réduit à zéro.

Exemple le plus célèbre sur PrestaShop

XsamXadoo Bot (janvier 2020). PrestaShop a détecté une faille critique exploitée par un malware qui passait par une vulnérabilité dans l’outil PHPUnit (CVE-2017-9841). Ce malware prenait le contrôle total de la boutique via les dossiers /vendor/phpunit/ présents dans le core ou dans certains modules. Les modules officiels touchés incluaient 1-Click Upgrade, Cart Abandonment Pro, Faceted Search, et PrestaShop Checkout. Le bot injectait des fichiers malveillants qui pouvaient ensuite servir à des redirections ou du défacement. Certains marchands ont été réinfectés en 2021 malgré avoir supprimé les dossiers PHPUnit, car des backdoors avaient été laissées.

C’est violent. Mais au moins, vous le voyez. Et vos clients aussi. On peut réagir vite !

La backdoor — l’intrus est chez vous et il a les clés

Le pirate a créé un accès permanent à votre boutique : un webshell planqué dans /override/, un cron piégé, un compte admin fantôme dans le back-office, une porte dérobée dans un module tiers. Il peut revenir même après un nettoyage. C’est pour ça que nettoyer sans trouver le point d’entrée ne sert à rien — vous jouez à un jeu de taupe.

Sur le forum PrestaShop, un marchand sous PS 8.0 témoignait en août 2024 : « Tous les jours, le site est infecté. J’ai beau nettoyer, ça revient et je n’ai pas encore identifié où est le point d’entrée. » C’est le scénario classique.

Ce qu’on oublie souvent : les clés d’API PrestaShop (menu Paramètres avancés > Webservice) sont aussi une porte d’entrée. Il suffit de quelques secondes dans le back-office pour copier une clé et accéder aux commandes et aux données clients.

Le skimmer — invisible, industriel, le cauchemar du e-commerce

Le plus dangereux, et de loin. Parce qu’il est conçu pour être indétectable.

Le script ne s’active que sur la page de checkout. Il se désactive quand un admin navigue. La commande passe normalement. Le marchand encaisse. Le client ne se doute de rien — jusqu’au relevé bancaire, des semaines plus tard.

Ce qu’on a dépanné chez des marchands PrestaShop : le skimmer reste actif des semaines, parfois des mois, sans que le marchand s’en rende compte. Le plus long cas documenté aux États-Unis : deux ans.

Mon conseil si vous avez un doute, demandez un dépannage PrestaShop en urgence. En effet, un PrestaShop piraté, ce n’est pas un WordPress piraté. Un WordPress piraté sert au spam SEO. Un PrestaShop piraté, c’est un distributeur de numéros de carte bancaire. Les enjeux ne sont pas les mêmes, et les conséquences non plus.

Du darkweb à la CNIL : la chaîne que personne ne vous dessine

Un piratage PrestaShop, ce n’est pas un ado dans un garage. C’est une chaîne industrielle avec des fournisseurs, des outils et un marché. Et le marchand est pris dans un engrenage qu’il ne voit pas.

Maillon 1 — Le darkweb : vos accès sont probablement déjà en vente

ZATAZ, le service de veille cybersécurité, a découvert 5 063 accès à des boutiques PrestaShop vendus à 100 dollars pièce sur le darkweb. Pour un pirate, c’est un investissement de 100 $ qui peut rapporter des milliers en données CB revendues.

Et il y a cette hypothèse que personne en France n’a relayée. Elle vient d’un article espagnol très documenté : les formulaires de support technique PrestaShop demandent l’URL du back-office, l’identifiant, le mot de passe et les accès FTP du marchand. Si ces données ont fuité côté PrestaShop… aucune faille technique n’est nécessaire. Le pirate entre par la porte d’entrée, avec les clés.

Nous avons communiqué plusieurs fois pour nos clients avec le support PrestaShop et c’est effectivement leur première demande. Nous la refusons systématiquement et la communication s’arrête là une fois sur deux sous prétexte de ne pas pouvoir auditer notre question sans ces accès.

Au-delà du darkweb, les modules tiers restent le vecteur n°1. Ce qu’on constate en infogérance PrestaShop : 90% des piratages passent par un module vulnérable. Les failles sont documentées publiquement, les exploits sont accessibles. Les attaquants n’ont même plus besoin de chercher — des bots scannent automatiquement, 24 heures sur 24.

Maillon 2 — Le skimmer : un outil industriel, assisté par l’IA

Le framework utilisé en février 2026 n’est pas artisanal. C’est un outil multi-plateforme qui supporte quatre CMS e-commerce et sept modes d’injection différents. Le « aggressive hiding mode » empêche même le JavaScript du site de réafficher le formulaire de paiement original.

Et voilà ce qui change la donne en 2026 : les attaquants utilisent l’IA générative pour produire des formulaires de paiement contrefaits localisés dans n’importe quelle langue, en quelques minutes. Un faux formulaire en français parfait, avec les logos de votre banque, généré automatiquement.

L’hébergement des serveurs d’exfiltration utilise du « bulletproof hosting », ce sont des hébergeurs qui ignorent les signalements d’abus. Les domaines changent toutes les semaines mais le pattern reste le même : un nom qui ressemble à un service connu pour ne pas éveiller les soupçons dans les DevTools.

Maillon 3 — Votre banque, la CNIL, et l’addition

Les données volées sont revendues en masse sur le darkweb ou utilisées directement pour des achats frauduleux. Les banques détectent les patterns de fraude liés à un marchand spécifique. À terme, elle peut suspendre votre contrat de paiement en ligne.

Côté légal : notification CNIL obligatoire sous 72 heures. Notification aux clients si risque élevé (et le vol de CB, c’est un risque élevé par définition).

La CNIL a reçu 17 483 notifications de violations entre 2018 et 2023. Le secteur privé représente deux tiers des déclarations, dont 39% de PME.

Et côté Google : il peut blacklister votre domaine du jour au lendemain. Message rouge pour tous vos visiteurs, SEO à zéro.

Le test de piratage PrestaShop : vérifiez votre boutique en 5 minutes

Maintenant que vous comprenez le mécanisme, passons à l’action. Ce test ne nécessite aucune compétence technique.

Étape 1 — Ouvrez une fenêtre de navigation privée

Ctrl+Maj+N sur Chrome, Cmd+Maj+N sur Mac. Pourquoi ? Parce que le skimmer détecte votre session admin et se désactive. En navigation privée, pas de session → vous voyez ce que voit votre client.

Précision importante : si votre boutique redirige vers la page de paiement de votre prestataire (type Stripe Checkout hébergé ou page de la banque), vous êtes moins exposé — les données CB ne transitent pas par votre serveur. Mais si votre module intègre un formulaire directement sur votre site (embedded form), le skimmer peut intercepter les données avant qu’elles n’atteignent le prestataire de paiement.

Étape 2 — Allez jusqu’au checkout avec un produit au panier

Observez les boutons de paiement. Sont-ils normaux ? Le formulaire CB est-il celui de votre prestataire de paiement ou un formulaire que vous ne reconnaissez pas ?

Étape 3 — Ouvrez les DevTools (F12), onglet Network

Regardez les requêtes réseau au moment où la page de paiement se charge. Si vous voyez des appels vers des domaines que vous ne reconnaissez pas, c’est probablement le skimmer qui exfiltre les données. Le point clé : le skimmer ne se charge que sur la page de checkout. Sur toutes les autres pages, le JavaScript est propre. C’est pour ça qu’un scan superficiel ne le détecte pas.

Étape 4 — Vérifiez le fichier head.tpl par FTP

Chemin : /themes/[votre-theme]/templates/_partials/head.tpl. Cherchez une balise <script> contenant atob() et XMLHttpRequest. La partie encodée en base64 change à chaque boutique infectée, mais la structure du code reste la même.

Vérifiez aussi la présence des modules mloader ou simplefilemanager dans le dossier /modules/. S’ils sont là, votre boutique est compromise — c’est dans l’alerte officielle de PrestaShop.

Vérifiez les dates de modification des fichiers .js dans /modules/ et /themes/. Un fichier modifié que vous n’avez pas touché = signal d’alerte immédiat.

Si vous trouvez quelque chose de suspect : ne touchez à rien. Ne supprimez rien. Descendez directement au protocole d’urgence. Si tout est propre : continuez quand même, parce que le prochain skimmer sera différent.

Le protocole d’urgence en 6 gestes — avant d’appeler un expert

Vous avez trouvé quelque chose, ou un client vous signale un prélèvement frauduleux après un achat sur votre boutique.

Voici exactement quoi faire dans les 30 prochaines minutes :

1. Couper l’accès public immédiatement. Si vous suspectez un skimmer, la priorité est de couper le module de paiement dans le back-office. Chaque commande qui passe expose une carte bancaire. Passez la boutique en mode maintenance. Si le BO est inaccessible, créez un fichier .maintenance à la racine ou modifiez le .htaccess pour renvoyer un code 503.
2. Changer TOUS les mots de passe. Tous, sans exception. Back-office (tous les employés, pas seulement le vôtre), FTP, base de données (et mettre à jour les identifiants dans parameters.php), panel hébergeur, emails associés. Et aussi les clés API des passerelles de paiement — si le pirate a eu accès au BO, il a pu modifier la configuration pour rediriger les paiements vers son propre compte. Les clés API Webservice PrestaShop aussi (Paramètres avancés > Webservice).
3. Vérifier et nettoyer le head.tpl. Supprimer le script malveillant. Mais attention — et c’est le point le plus important de cet article : supprimer le script ne règle pas la cause. Si quelqu’un a pu écrire dans vos fichiers, considérez le site comme compromis jusqu’à preuve du contraire. Vérifiez aussi le footer, les templates checkout, les fichiers JS des modules, les overrides. Après nettoyage : purgez tous les caches — PrestaShop, Smarty, Symfony, et Cloudflare si vous l’utilisez. Le script malveillant peut y rester stocké.
4. Checker les comptes admin et les modules. Paramètres avancés > Équipe > Employés. Supprimez tout compte que vous ne reconnaissez pas, surtout ceux créés récemment. Les pirates créent des comptes admin backdoor pour revenir même après le nettoyage. Vérifiez les modules installés : supprimez tout module inconnu. Et les modules désactivés mais encore présents sur le serveur ? Supprimez les dossiers, pas seulement désactiver.
5. Contacter l’hébergeur — et lui demander de CONSERVER les logs. C’est le piège que personne ne mentionne : beaucoup d’hébergeurs suppriment involontairement les preuves cruciales — rotation des logs mal configurée, suppression automatique trop rapide. Demandez explicitement la conservation des access logs et error logs des 30 derniers jours AVANT tout nettoyage. Sans ces logs, vous ne saurez jamais par où le pirate est entré.
6. Sauvegarder le site compromis et documenter. Contre-intuitif, mais indispensable. Sauvegardez l’état compromis (fichiers + base de données) pour l’analyse forensique et le dossier CNIL. Captures d’écran du code malveillant, dates de modification des fichiers, liste des comptes admin suspects. Vous avez 72 heures pour notifier la CNIL — ce dossier est la base de votre notification.

Ce qu’on voit lors de nos dépannages PrestaShop : dans 90% des cas, le point d’entrée est un module tiers non mis à jour depuis plus d’un an. Le skimmer est la conséquence. Le module vulnérable est la cause.

Pourquoi le nettoyage seul de PrestaShop ne suffit pas ?

La plupart des articles s’arrêtent à « nettoyez les fichiers et changez vos mots de passe ». Ca ne suffit presque jamais !

Le nettoyage sans identification du point d’entrée, c’est la garantie de la réinfection. Le marchand du forum PrestaShop dont je parlais plus haut l’a vécu : nettoyage tous les jours, infection tous les jours. Mais le point d’entrée n’était pas identifié.

Le vrai nettoyage professionnel, c’est autre chose : réinstaller les fichiers core PrestaShop depuis une source officielle, comparer chaque fichier modifié avec l’original, identifier le module coupable, supprimer les webshells dans /override/, les crons piégés, les backdoors dans les templates Smarty, nettoyer la base de données, et monitorer pendant 30 jours minimum.

Le coût moyen chez un spécialiste sécurité : 1 000 à 5 000 €. Chez CYBERIAL : le forfait dépannage PrestaShop à 150 € HT fonctionne dans la majorité des cas. Le forfait maintenance à 69 €/mois qui aurait empêché tout ça paraît dérisoire en comparaison.

Au passage, un module vérolé peut aussi expliquer une boutique anormalement lente. On a vu des scripts de minage de cryptomonnaies planqués dans des modules, qui saturent le CPU du serveur en arrière-plan pendant que le marchand cherche pourquoi son site rame.

Vos obligations légales — ce que 95% des marchands ignorent

Ce qui suit, la plupart de nos clients le découvrent après le piratage. Mieux vaut le savoir avant.

Notification CNIL sous 72 heures — non optionnel

Vol de données CB = violation de données à caractère personnel = notification obligatoire à la CNIL. Article 33 du RGPD. Ce n’est pas « si vous avez le temps ». C’est 72 heures maximum après avoir pris connaissance de la violation.

Comment faire concrètement : un téléservice sur cnil.fr. Si vous ne pouvez pas fournir toutes les informations dans les 72 heures, faites une notification initiale puis complétez dès que possible. Mais si vous dépassez le délai, vous devez expliquer pourquoi.

Notification aux clients — le dilemme

Si le risque est élevé (et le vol de coordonnées bancaires, c’est un risque élevé par définition), vous devez informer directement les personnes concernées. Individuellement si possible. Article 34 du RGPD.

C’est le dilemme que tout marchand redoute. Informer les clients, c’est risquer la perte de confiance. Mais ne pas les informer, c’est une infraction RGPD. Ce n’est plus un choix éthique — c’est une obligation légale.

Mon conseil : informez de manière factuelle, expliquez les mesures prises, proposez de l’aide. C’est mieux que de l’apprendre par la presse ou par un prélèvement frauduleux.

Déposer plainte

Les ressources que personne ne connaît :

• 17Cyber.gouv.fr : le guichet Police/Gendarmerie/Cybermalveillance, disponible 24 heures sur 24, 7 jours sur 7. Diagnostic en quelques questions, conseils personnalisés. Personne ne le mentionne dans les articles concurrents — et pourtant c’est la première ressource officielle.
• Cybermalveillance.gouv.fr : plus de 1 200 prestataires référencés, dont 200 labellisés ExpertCyber. Fiches réflexes téléchargeables gratuitement.
• Le guide Bpifrance × Cybermalveillance : un plan d’action complet en cas de cyberattaque pour les TPE/PME. PDF gratuit.

PCI-DSS — l’épée de Damoclès

Les amendes PCI-DSS vont de 5 000 à 100 000 euros par mois pour non-conformité. La banque peut suspendre ou révoquer votre contrat de paiement — vous ne pouvez plus encaisser de CB.

Une brèche qui compromet des données bancaires vous fait automatiquement passer au niveau de conformité PCI le plus élevé, avec audit complet obligatoire.

Les modules : 90% des portes d’entrée

Si votre boutique a été piratée, il y a neuf chances sur dix que la porte d’entrée soit un module. Pas le cœur de PrestaShop. Un module.

Les CVE récentes qui ont ouvert des portes

Ce que dénonce TouchWeb — et c’est un problème systémique : de nombreux éditeurs de modules ne publient pas leurs vulnérabilités. Ils préfèrent taire leurs failles plutôt que de les assumer. Tant que ces vulnérabilités ne sont pas reconnues et traitées, elles restent exploitables pendant des années.

Voici les dernières failles connues au moment où j’écris cet article :

• Février 2026 : Advanced Popup Creator, injection SQL, sévérité critique 9.8 sur 10. Un attaquant non authentifié peut exécuter n’importe quelle requête dans votre base de données.
• Octobre 2025 : le module Checkout/PayPal officiel — prise de contrôle de compte client via Express Checkout. Même les modules « officiels » ont des failles.
• Septembre 2025 : fuite d’emails admin via la page de réinitialisation de mot de passe (CVE-2025-51586). Le pirate peut énumérer tous les comptes admin sans être authentifié.
• Et en mars 2026, deux nouvelles advisories GitHub sur le cœur de PrestaShop : une XSS stockée (sévérité High) et un contournement du framework de validation. Le cœur continue de recevoir des patches — ceux qui ne mettent pas à jour restent vulnérables.

Le piège des modules « nulled »

Les modules pirates et téléchargés hors marketplace officielle, c’est la porte dérobée intégrée dès l’installation. Le hacker fait uploader un fichier via la faille d’un module, puis modifie les processus de PrestaShop.

Les modules désactivés mais encore présents sur le serveur restent une surface d’attaque. La règle : supprimez les dossiers, pas seulement désactiver. Supprimez aussi les anciennes installations de PrestaShop et les zones de dev.

Comment vérifier un module avant de l’installer

Il faut vérifier trois critères essentiels avant d’installer un module PrestaShop :

1. Date de dernière mise à jour : un module non mis à jour depuis plus d’un an est un risque.
2. CVE connues : vérifiez sur security.friendsofpresta.org avant d’installer.
3. Source : marketplace officielle ou éditeur reconnu avec charte de sécurité transparente.

Et un outil gratuit : PrestaScan Security, module open-source sur GitHub, qui scanne les malwares et CVE connues dans le cœur et les modules. Compatible PrestaShop 1.5 à 8.

Comment éviter que ça se reproduise

Pour éviter de se faire pirater sa boutique PrestaShop, il faut revenir à un sujet de base : la maintenance préventive de PrestaShop.

• Mettre à jour PrestaShop, les modules et le thème. C’est la base car les failles sont documentées, les exploits sont publics. Ainsi, des bots automatiques cherchent 24/24 des boutiques non mises à jour et quand ils en trouvent une, le piratage prend moins de trois minutes.
• Supprimer les modules inutilisés. Chaque module installé est une surface d’attaque. Supprimer les dossiers, pas seulement désactiver. Supprimer aussi les anciennes installations, les zones de test, les dossiers oubliés.
• Renommer le dossier admin du back-office. Le nom par défaut est connu de tous les scanners automatisés.
• Activer la double authentification sur le back-office ET le panel hébergeur.
• Sauvegardes externalisées quotidiennes. Pas seulement celles de l’hébergeur — la rétention est souvent de 7 jours seulement. Si le piratage est détecté au bout de 15 jours, aucune sauvegarde saine. Sauvegardez fichiers et base de données, sur un stockage externe, et testez la restauration régulièrement.
• Surveiller les dates de modification des fichiers. Un fichier .js ou .tpl modifié que vous n’avez pas touché = signal d’alerte immédiat.
• Et le vrai filet de sécurité : un prestataire qui surveille 7 jours sur 7, qui met à jour avant que les failles soient exploitées, et qui intervient en priorité quand ça arrive.

Votre boutique est piratée en ce moment ? On intervient sous 24h. Appelez-nous directement au 09 72 03 59 17— 7j/7, de 8h à 22h.

Et si vous en avez assez de découvrir les pannes en même temps que vos clients : le forfait maintenance CYBERIAL à 69 €/mois inclut la surveillance quotidienne, les mises à jour proactives et l’intervention prioritaire.