Votre PrestaShop est piraté,on le nettoie gratuitement

Les signaux qui doivent vous alerter : un client signale un prélèvement frauduleux après un achat chez vous, votre banque vous écrit, votre boutique redirige vers un site inconnu, des titres de pages en langue étrangère apparaissent dans Google, un compte employé que vous ne reconnaissez pas figure dans le back-office, ou des fichiers ont été modifiés à une date où vous n’avez rien touché. Le plus dangereux ne donne aucun signal : le skimmer. Pour celui-là, il faut faire le test.

Parce que le skimmer qui circule sur PrestaShop détecte votre session d’administrateur et se désactive. Vous naviguez sur votre boutique, vous passez une commande test, tout paraît normal. Vos clients, eux, voient un faux formulaire de paiement. C’est la particularité qui rend ce malware redoutable : le marchand ne peut littéralement pas le voir en naviguant sur sa propre boutique.

Aucune compétence technique n’est requise. Quatre étapes :

• Ouvrez une fenêtre de navigation privée (Ctrl + Maj + N sur Chrome, Cmd + Maj + N sur Mac, Ctrl + Maj + P sur Firefox). Pas de session admin, donc vous voyez ce que voit votre client.
• Ajoutez un produit au panier et allez jusqu’à la page de paiement. Les boutons sont-ils bien ceux de votre prestataire de paiement ? Un formulaire de carte que vous ne reconnaissez pas est suspect.
• Ouvrez les outils de développement (touche F12), onglet Réseau, et regardez les requêtes qui partent au chargement de la page de paiement. Des appels vers des domaines inconnus sont un signal fort.
• Vérifiez le fichier head.tpl par FTP.

Point clé : le skimmer ne se charge que sur le tunnel de commande. Sur toutes les autres pages, le code est propre. C’est pour ça qu’un scan superficiel ne le voit pas.

Le chemin à ouvrir : /themes/[votre-theme]/templates/_partials/head.tpl. Cherchez une balise <script> qui contient 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 le pied de page, les templates du tunnel de commande, les fichiers .js des modules et les /override/.

La présence de mloader ou de simplefilemanager dans le dossier /modules/ signe une boutique compromise. Ces deux noms figurent dans l’alerte officielle de PrestaShop. Si vous les trouvez, ne les supprimez pas : appelez-nous, ils font partie des preuves.

Trois outils que nous utilisons ou recommandons :

• Sansec eComscan : la référence sur les skimmers Magecart. Il compare vos fichiers cœur avec les originaux et débusque le code injecté. Payant, mais c’est le plus fiable.
• Sucuri SiteCheck : un scan en ligne gratuit, en trente secondes, depuis l’extérieur. Pratique pour un premier avis.
• ImunifyAV : si votre hébergeur le propose, un scan côté serveur directement sur vos fichiers.

Et un module gratuit et open source : PrestaScan Security, qui scanne les malwares et les failles connues dans le cœur et les modules, compatible PrestaShop 1.5 à 8.

Non, et c’est le piège du faux négatif. Ces outils scannent, ils ne nettoient pas, et surtout beaucoup n’analysent que la page d’accueil. Le skimmer ne se charge que sur le tunnel de commande : un scan qui ne teste pas le checkout ne verra rien. Testez explicitement le parcours d’achat.

Oui. Un module vérolé explique parfois une lenteur inexpliquée. On a déjà trouvé des scripts de minage de cryptomonnaie planqués dans des modules, qui saturent le processeur du serveur en arrière-plan pendant que le marchand cherche pourquoi son site rame.

Regardez les dates de modification des fichiers .js et .tpl dans /modules/ et /themes/. Un fichier modifié à une date où personne n’est intervenu est un signal d’alerte immédiat. Dans un dossier que nous avons traité, cette seule date a révélé une compromission vieille de quatre ans.

Dans cet ordre, et rien d’autre :

• Coupez le paiement. Désactivez le module de paiement dans le back-office, ou passez la boutique en maintenance. Chaque commande qui passe expose une carte de plus.
• Ne supprimez rien. Ni le script, ni les fichiers suspects, ni les journaux.
• Faites auditer. Le nettoyage à l’aveugle garantit la réinfection.

Ensuite viennent le changement des mots de passe, la conservation des journaux chez l’hébergeur et la sauvegarde de l’état compromis. Si vous préférez qu’on reprenne la main tout de suite, appelez le 09 72 03 59 17.

Parce que ce que vous voyez, ce sont vos preuves. Elles servent à deux choses : retrouver le point d’entrée, sans lequel le nettoyage ne tiendra pas, et constituer votre dossier de notification à la CNIL. Un marchand qui efface tout dans la panique se retrouve avec une boutique qui se réinfecte et un dossier vide.

Créez un fichier .maintenance à la racine, ou modifiez le .htaccess pour renvoyer un code 503. Affichez un message clair aux visiteurs, du type « maintenance de sécurité en cours ». Une boutique coupée pendant quelques heures coûte infiniment moins cher qu’une boutique qui continue à distribuer des cartes bancaires.

Tous, sans exception : le back-office pour tous les employés et pas seulement le vôtre, le FTP, la base de données avec mise à jour des identifiants dans parameters.php, le panneau de l’hébergeur, les adresses e-mail associées. Et surtout les clés d’API des passerelles de paiement : si le pirate a eu accès au back-office, il a pu modifier la configuration pour rediriger les paiements vers son propre compte. Les clés Webservice de PrestaShop aussi, dans Paramètres avancés puis Webservice : quelques secondes suffisent pour en copier une et accéder aux commandes et aux données clients.

C’est le piège que personne ne mentionne. Beaucoup d’hébergeurs suppriment involontairement les preuves : rotation des journaux mal configurée, effacement automatique trop rapide. Demandez explicitement la conservation des journaux d’accès et d’erreurs des trente derniers jours, avant tout nettoyage. Sans eux, vous ne saurez jamais par où le pirate est entré.

Oui, et c’est contre-intuitif. Sauvegardez l’état compromis, fichiers et base de données, avant d’y toucher. C’est la matière première de l’analyse et de votre dossier CNIL. Prenez aussi des captures d’écran du code malveillant, notez les dates de modification des fichiers et la liste des comptes suspects. Vous avez soixante-douze heures pour notifier, et c’est la base de votre déclaration.

Allez dans Paramètres avancés, Équipe, Employés. Notez et signalez tout compte que vous ne reconnaissez pas, surtout ceux créés récemment : les pirates créent des comptes administrateur de secours pour revenir après le nettoyage. Même logique pour les modules installés que vous n’avez jamais demandés.

Un script qui s’intercale dans votre tunnel de commande pour capter les cartes bancaires de vos clients. Soit en remplaçant vos boutons de paiement par de faux, soit en surveillant en silence les champs du formulaire. La commande passe, vous encaissez, personne ne voit rien. Jusqu’au relevé bancaire, des semaines plus tard.

Le mécanisme est diaboliquement efficace. Le client clique sur payer, tombe sur un faux formulaire, saisit ses données. Le formulaire affiche une erreur. Le client croit s’être trompé, recommence, et cette fois c’est le vrai formulaire. La commande passe, le marchand encaisse, le client reçoit sa confirmation. Tout paraît normal. Sauf que les données bancaires viennent d’être copiées et envoyées à un serveur contrôlé par les pirates.

Le 12 février 2026, les marchands PrestaShop ont reçu un e-mail de l’éditeur intitulé « Alerte de sécurité », évoquant un vol d’informations de paiement. Beaucoup ont cru à une tentative d’hameçonnage. Quelques jours plus tôt, le chercheur en cybersécurité Clément Domingo avait publié l’analyse technique de la menace. Le 23 février, une caisse régionale du Crédit Agricole envoyait des courriers recommandés à ses clients e-commerçants, leur demandant de faire vérifier leur site. La vraie question reste ouverte : combien de marchands ont ignoré cet e-mail parce qu’il ressemblait à du spam, et combien de boutiques sont encore infectées aujourd’hui ?

C’est le premier réflexe à vérifier pour savoir à quel point vous êtes une cible. Si votre boutique redirige vers la page hébergée de votre prestataire ou de votre banque, les données de carte ne transitent pas par votre serveur et le skimmer a beaucoup moins de prise. Si le formulaire est intégré à votre thème, le skimmer intercepte les données avant qu’elles n’atteignent le prestataire. Intégré ne veut pas dire mal fait, mais ça veut dire plus exposé.

Les attaquants s’adaptent, et trois variantes circulent déjà :

• Exfiltration par WebSocket : les données partent par une connexion ouverte en arrière-plan, bien plus discrète qu’un appel réseau visible dans l’onglet Réseau.
• Injection dans un attribut SVG : le code est planqué dans l’attribut onload d’une image, pas dans le template.
• Domaine d’exfiltration déguisé : le serveur qui reçoit les cartes porte un nom qui imite un service légitime, faux service d’analyse ou faux réseau de diffusion. Dans les outils de développement, rien ne saute aux yeux.

Le défacement et les redirections : visible immédiatement, détecté en quelques heures, risque faible sur les données bancaires. La backdoor : difficile à voir, détectée en jours ou en semaines, risque élevé. Le skimmer : invisible, détecté en semaines ou en mois, risque critique. Trois piratages, trois réactions différentes. Le plus visible est le moins grave.

Dans neuf cas sur dix que nous traitons, par un module tiers non mis à jour depuis plus d’un an. Pas par le cœur de PrestaShop. Les failles sont documentées publiquement, les codes d’exploitation sont accessibles, et des robots scannent en continu. Quand ils trouvent une boutique non à jour, le piratage prend moins de trois minutes. Le skimmer est la conséquence, le module vulnérable est la cause.

Oui. Le service de veille ZATAZ a découvert 5 063 accès à des boutiques PrestaShop vendus une centaine de dollars pièce sur le darkweb. Pour un attaquant, c’est un investissement dérisoire au regard de ce que rapportent les données bancaires revendues. Dans ce cas de figure, aucune faille technique n’est nécessaire : il entre par la porte, avec les clés.

Industriel. Le cadre logiciel utilisé en février 2026 supporte quatre plateformes e-commerce et sept modes d’injection. Un mode dit agressif empêche même le code de votre site de réafficher le formulaire de paiement d’origine. Les attaquants utilisent désormais l’IA générative pour produire des formulaires contrefaits dans n’importe quelle langue, en quelques minutes, avec les logos de votre banque. L’hébergement des serveurs d’exfiltration passe par des prestataires qui ignorent les signalements d’abus, et les domaines changent chaque semaine.

Oui, et ce n’est pas une formule. Un WordPress compromis sert le plus souvent à du spam de référencement. Un PrestaShop compromis est un distributeur de numéros de carte bancaire. Les enjeux ne sont pas les mêmes, les obligations légales non plus, et les conséquences financières encore moins.

Parce que ça traite le symptôme et pas la cause. Si quelqu’un a pu écrire dans vos fichiers, considérez le site comme compromis jusqu’à preuve du contraire. Sur le forum PrestaShop, un marchand résumait la situation en août 2024 : il nettoyait tous les jours, le site était réinfecté tous les jours, et le point d’entrée n’avait jamais été identifié. C’est le scénario le plus fréquent.

Réinstaller les fichiers du cœur depuis la source officielle, comparer chaque fichier modifié avec l’original, identifier le module coupable, supprimer les webshells dans /override/, les tâches planifiées piégées et les portes dérobées dans les templates, nettoyer la base de données, purger tous les caches (PrestaShop, Smarty, Symfony, et le réseau de diffusion s’il y en a un, où le script malveillant peut rester stocké), renouveler l’ensemble des accès, puis surveiller pendant trente jours minimum.

C’est la signature d’une backdoor toujours en place : un webshell, une tâche planifiée, un compte administrateur fantôme ou une clé d’API restée valide. Tant que la porte reste ouverte, vous nettoierez tous les jours. C’est exactement le genre de dossier pour lequel on cherche d’abord le point d’entrée, avant de toucher au reste.

Le diagnostic démarre pendant l’appel. Un nettoyage courant est traité sous vingt-quatre heures. Une compromission ancienne, avec plusieurs portes dérobées et un parc de modules abandonné, demande plus de temps. On vous le dit avant de commencer, pas après.

Non. On sauvegarde fichiers et base avant toute intervention. Les contenus, les commandes, les clients et le thème reviennent à l’identique. Ce qui disparaît, c’est le code injecté et les accès du pirate.

Il n’y en a pas. Diagnostic, nettoyage, recherche du point d’entrée et rapport écrit : 0 €. Sans abonnement, sans engagement, sans contrepartie. Vous ne signez rien. Si vous voulez ensuite une surveillance pour que ça ne recommence pas, elle existe et elle est payante. C’est un autre sujet, et c’est vous qui décidez.

Chez un spécialiste sécurité, le marché se situe le plus souvent entre 1 000 et 5 000 € selon l’ancienneté de la compromission et l’étendue de l’analyse. C’est un tarif légitime pour le travail fourni. Nous avons fait un autre choix : le nettoyage d’une boutique piratée ne devrait pas dépendre de la trésorerie du marchand au moment où ça lui tombe dessus.

Oui. On passe par le FTP ou la base pour rétablir un accès administrateur sain, puis on vérifie qu’aucun compte pirate ne subsiste et on renouvelle l’ensemble des identifiants.

La méfiance est saine, surtout sur ce sujet précis. Nous sommes agence PrestaShop certifiée Expert, immatriculée en France, avec 44 avis Google vérifiés et plus de 350 boutiques en gestion. Vous créez un accès dédié, vous le révoquez à la fin de l’intervention, et chaque action menée figure dans le rapport écrit. À noter au passage : nous refusons systématiquement de communiquer les identifiants d’un client à un tiers, quel qu’il soit.

Ce n’est pas un problème. On intervient à distance, chez n’importe quel hébergeur, sans contrat préalable, et sans rien changer à votre relation avec votre prestataire actuel. Si votre agence habituelle veut reprendre la main après le nettoyage, le rapport lui donne tout ce qu’il faut.

Un vol de données bancaires est une violation de données à caractère personnel, donc la notification est obligatoire. Article 33 du RGPD, soixante-douze heures maximum après avoir pris connaissance de la violation. Ce n’est pas « si vous avez le temps ». La démarche se fait par téléservice sur cnil.fr. Si vous ne pouvez pas tout fournir dans le délai, faites une notification initiale puis complétez ; si vous dépassez, vous devez expliquer pourquoi.

Un document écrit, daté et factuel. Le gabarit à remplir :

• Date de découverte
• Nature de la faille : malware, skimmer, intrusion, module compromis
• Intrusion confirmée ou suspectée
• Base de données consultée ou extraite : oui ou non
• Données concernées
• Nombre de personnes concernées
• Mesures correctives prises : nettoyage du code, scan de sécurité, réinitialisation des accès, pare-feu applicatif

Si vous êtes accompagné par un mainteneur, c’est à lui de vous fournir ce document. C’est ce que contient notre rapport.

C’est la situation normale avec un skimmer, et c’est parfaitement recevable. La charge malveillante n’est jamais stockée en clair sur le site : c’est le serveur du pirate qui l’injecte à la volée. Personne ne reconstituera la liste précise des victimes. Vous déclarez donc un périmètre probable, pas une certitude. La CNIL attend de la transparence, pas de la divination.

Si le risque est élevé, et le vol de coordonnées bancaires l’est 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, c’est risquer la confiance ; ne pas informer, c’est une infraction. Notre conseil : soyez factuel, expliquez les mesures prises, proposez de l’aide. C’est toujours mieux que de l’apprendre par un prélèvement frauduleux.

Trois ressources officielles, trop peu connues :

• 17Cyber.gouv.fr : le guichet Police, Gendarmerie et Cybermalveillance, ouvert vingt-quatre heures sur vingt-quatre. Diagnostic en quelques questions et conseils personnalisés.
• Cybermalveillance.gouv.fr : plus de 1 200 prestataires référencés, dont environ 200 labellisés ExpertCyber, et des fiches réflexes gratuites.
• Le guide Bpifrance et Cybermalveillance : un plan d’action complet et gratuit en cas de cyberattaque pour les TPE et PME.

Les amendes PCI-DSS vont de 5 000 à 100 000 € par mois pour non-conformité. Les banques détectent les schémas de fraude liés à un marchand donné et peuvent suspendre ou révoquer votre contrat de paiement en ligne : vous n’encaissez plus par carte. Une brèche qui compromet des données bancaires vous fait aussi basculer au niveau de conformité le plus élevé, avec audit complet obligatoire.

Google peut blacklister un domaine en quelques heures : bandeau rouge pour tous vos visiteurs, référencement à zéro, campagnes publicitaires suspendues. La sortie passe par un nettoyage complet, la vérification qu’aucune trace ne subsiste dans les pages indexées, puis une demande de réexamen depuis la Search Console. Tant que le code est encore là, la demande est refusée.

Les gestes qui évitent la grande majorité des cas :

• Mettre à jour PrestaShop, les modules et le thème. C’est la base.
• Supprimer les modules inutilisés, les anciennes installations et les zones de test oubliées.
• Renommer le dossier d’administration : le nom par défaut est connu de tous les scanners.
• Activer la double authentification sur le back-office et sur le panneau de l’hébergeur.
• Externaliser les sauvegardes quotidiennes, fichiers et base, et tester la restauration.
• Surveiller les dates de modification des fichiers.

Trois critères, dans cet ordre. La date de dernière mise à jour : au-delà d’un an sans correctif, c’est un risque. Les failles connues : vérifiez sur security.friendsofpresta.org et dans les avis de sécurité GitHub de PrestaShop. La source : marketplace officielle ou éditeur reconnu avec une charte de sécurité transparente. Un point systémique à connaître : de nombreux éditeurs ne publient pas leurs vulnérabilités, qui restent donc exploitables pendant des années.

Quelques cas marquants : en février 2026, une injection SQL de sévérité critique dans un module de fenêtres surgissantes, permettant à un attaquant non authentifié d’exécuter n’importe quelle requête en base. En octobre 2025, une prise de contrôle de compte client via le module de paiement officiel : même les modules officiels ont des failles. En septembre 2025, une fuite d’adresses d’administrateurs via la page de réinitialisation de mot de passe (CVE-2025-51586). En mars 2026, deux nouveaux avis sur le cœur, dont une faille de type XSS stockée. Plus ancien mais toujours instructif : le bot XsamXadoo de janvier 2020, qui passait par une vulnérabilité d’un composant tiers présent dans le cœur et dans plusieurs modules officiels. Certains marchands ont été réinfectés un an plus tard, parce que des portes dérobées avaient été laissées.

Un module piraté, téléchargé hors marketplace officielle, c’est la porte dérobée intégrée dès l’installation. Vous n’êtes pas victime d’une faille, vous l’installez vous-même. Économiser quelques dizaines d’euros de licence pour ouvrir un accès permanent à votre base clients n’est jamais une bonne affaire.

Non. Un module désactivé mais toujours présent sur le serveur reste une surface d’attaque : ses fichiers restent accessibles. La règle est simple : supprimez les dossiers, ne vous contentez pas de désactiver. Même chose pour les anciennes installations de PrestaShop et les copies de développement laissées dans un sous-dossier.

Rarement. La rétention est souvent de sept jours. Si le piratage est détecté au bout de quinze jours, toutes les sauvegardes disponibles contiennent déjà l’infection, et vous n’avez plus aucun point de retour sain. Il faut des sauvegardes externalisées, fichiers et base, avec une rétention plus longue et une restauration testée régulièrement. Sinon, c’est une assurance dont personne n’a lu le contrat.