Prestashop piraté / hacké : Le guide du nettoyage

Mis à jour le 21 octobre 2026

Lire la vidéo sur le piratage1 min 13

Les 3 réflexes avant de toucher à quoi que ce soit

Un piratage se traite dans un ordre précis. Trois points sont à sécuriser avant la moindre suppression de fichier, sous peine de perdre l'information qui permet de comprendre par où l'attaquant est entré.

• 1. Figez une copie de l'état actuel. Avant de nettoyer, sauvegardez la boutique telle qu'elle est, infectée. C'est cette copie qui contient les dates de modification et les fichiers ajoutés, donc la trace de l'intrusion. Une fois le ménage fait, cette information n'existe plus.
• 2. Ne restaurez pas une sauvegarde immédiatement. Une intrusion est généralement découverte bien après avoir eu lieu. Les sauvegardes des dernières semaines contiennent donc souvent déjà la porte dérobée, et les restaurer revient à remettre le problème en ligne. Il faut d'abord dater l'intrusion.
• 3. Coupez l'accès public si des données clients sont en jeu. Si le tunnel de commande est touché, chaque commande passée expose un nouveau client. Le mode maintenance arrête l'hémorragie le temps du diagnostic.

Un dernier point, souvent traité trop tard : renouvelez les mots de passe FTP, base de données, back office et hébergeur. Tant que les identifiants qui ont servi à entrer restent valides, le nettoyage ne tient pas.

Confirmer le piratage : 6 vérifications

Un comportement anormal ne signifie pas toujours une intrusion : un module défaillant produit parfois les mêmes symptômes. Ces six vérifications permettent de trancher, de la plus rapide à la plus technique.

• 1. Search Console, rapport Problèmes de sécurité. Google y signale les contenus piratés qu'il a détectés, avec des URLs d'exemple. C'est la vérification la plus rapide et la plus fiable quand elle remonte quelque chose. Un rapport vide ne prouve rien, Google ne détecte pas tout.
• 2. La commande site:votredomaine.fr dans Google, liste vos pages indexées. Vérifier avec des termes liés au hacking si de nouvelles pages ressortent.
• 3. L'inspection d'URL de Search Console. Elle affiche le HTML que Google a réellement reçu, qui peut différer de ce que vous voyez dans votre navigateur. C'est le seul moyen simple de repérer un contenu servi uniquement aux moteurs.
• 4. La comparaison avec l'archive officielle. Téléchargez le zip de votre version exacte de PrestaShop depuis le site officiel, et comparez son contenu avec vos fichiers. Tout fichier en trop dans le coeur, ou tout fichier du coeur modifié, est un signal direct. C'est la méthode la plus fiable, parce qu'elle ne dépend d'aucune signature connue.
• 5. Les fichiers récemment modifiés. En SSH, find . -type f -name "*.php" -mtime -30 liste les fichiers PHP touchés dans les trente derniers jours. Les dates se regroupent en général autour du jour de l'intrusion, ce qui la date précisément.
• 6. La table des comptes administrateurs. Dans la base, la table ps_employee (le préfixe peut différer) doit ne contenir que des comptes que vous reconnaissez. Un compte inconnu, ou une adresse e-mail modifiée sur un compte existant, confirme l'accès au back office.

Les fichiers ajoutés par une attaque sont rarement lisibles. Ils contiennent le plus souvent du code encodé, reconnaissable à des fonctions comme eval, base64_decode, gzinflate ou str_rot13, parfois enchaînées sur une seule ligne très longue. Rechercher ces termes dans l'arborescence remonte les fichiers à examiner en priorité, sachant que certains modules légitimes les utilisent aussi.

Trouvez votre cas en une question

Une seule question à vous poser : qu'est-ce que vous constatez ? Trouvez la ligne qui correspond, allez directement au cas indiqué. Une même intrusion combine souvent plusieurs de ces formes, alors revenez à ce tableau après avoir traité un cas.

Cas 1 : spam SEO, le hack pharmacie

Symptôme. Google indexe sur votre domaine des centaines ou des milliers de pages qui parlent de médicaments, de contrefaçon de luxe, de jeu en ligne ou de crédit. Le site, lui, s'affiche normalement. C'est la forme de piratage la plus fréquente sur les boutiques en ligne, et la plus longue à réparer.

Pourquoi. L'attaquant ne cherche pas à nuire à votre boutique, il emprunte son autorité. Un domaine e-commerce établi depuis plusieurs années a une crédibilité aux yeux de Google qu'un domaine neuf n'a pas : les pages spam qu'il y greffe se positionnent bien plus vite que sur un site créé pour l'occasion. Votre référencement est la marchandise.

Ces pages sont presque toujours servies de façon sélective. Un visiteur normal qui ouvre l'URL voit une page d'erreur ou votre accueil, alors que Googlebot reçoit la page spam complète. C'est pourquoi l'inspection d'URL de Search Console est indispensable ici : elle est le seul point de vue qui compte.

Correction.

1. Relevez la liste complète des URLs spam indexées, via site: et via l'export du rapport Pages de Search Console. C'est cette liste qui pilotera tout le travail de désindexation.
2. Identifiez le mécanisme d'injection : fichier ajouté dans le thème ou dans un module, contenu inséré en base, ou règle ajoutée au .htaccess.
3. Supprimez les fichiers ajoutés et nettoyez les entrées injectées en base.
4. Régénérez le .htaccess depuis le back office, section Trafic & SEO, plutôt que de le corriger à la main.
5. Traitez les URLs indexées, ce qui est un chantier à part entière : voir la section réparer le SEO.

Ça n'a rien changé et le spam revient ? Une porte dérobée est encore active, passez au cas 3.

Cas 2 : redirection conditionnelle

Symptôme. Des clients signalent avoir été redirigés vers un autre site, alors que vous ne reproduisez pas le problème. La redirection ne se déclenche souvent que sur mobile, ou seulement quand le visiteur arrive depuis un résultat Google.

Pourquoi. Le code injecté teste des conditions avant d'agir : le referer, c'est-à-dire la provenance du visiteur, qui permet de ne se déclencher que sur une arrivée depuis Google ; le type d'appareil ; la présence d'un cookie déjà posé. Un visiteur qui revient n'est pas redirigé une seconde fois, et l'administrateur qui tape l'adresse directement ne l'est jamais. C'est ce qui explique le décalage entre les signalements clients et ce que vous constatez.

Correction.

1. Reproduisez le déclenchement : navigation privée, depuis un résultat Google, en simulant un mobile via les outils de développement du navigateur.
2. Inspectez le .htaccess à la racine et dans les sous-dossiers, où ce type de règle est fréquemment posé.
3. Examinez les fichiers JavaScript du thème, ainsi que les scripts injectés depuis la base, notamment dans les contenus éditoriaux et la configuration.
4. Vérifiez les modules qui insèrent du code dans le pied de page ou l'en-tête, cible commode car le code s'y retrouve sur toutes les pages.

La redirection persiste après nettoyage des fichiers ? Le code est réinjecté, passez au cas 3.

Cas 3 : porte dérobée et webshell

Symptôme. Le site a été nettoyé, et l'infection revient au bout de quelques jours. Ou un compte administrateur inconnu apparaît dans le back office, parfois après avoir été supprimé une première fois.

Pourquoi. C'est la couche qui rend toutes les autres persistantes. Une porte dérobée est un fichier qui permet à l'attaquant d'exécuter du code sur le serveur sans identifiants, en appelant simplement une URL. Tant qu'elle est en place, supprimer les pages spam ou les redirections ne sert à rien : elles seront réécrites.

Ces fichiers sont conçus pour ne pas se voir. Ils portent des noms plausibles, sont placés dans des dossiers légitimes comme img/, upload/, modules/ ou override/, et sont souvent multiples : en trouver un ne signifie pas les avoir tous trouvés.

Correction.

1. Comparez systématiquement l'arborescence avec l'archive officielle de votre version. C'est le seul moyen de repérer un fichier qui n'a rien à faire là, quel que soit son nom.
2. Cherchez les fichiers PHP présents dans les dossiers qui ne devraient contenir que des images ou des documents.
3. Videz la table des comptes administrateurs de toute entrée non reconnue, et changez le mot de passe des comptes légitimes.
4. Renommez le dossier d'administration si son nom est celui d'origine, et vérifiez les tâches planifiées côté hébergeur, qui peuvent relancer un script à intervalle régulier.

Vous ne trouvez pas le point d'entrée et le site se réinfecte ? C'est le cas où l'intervention d'un spécialiste se justifie le plus.

Cas 4 : vol de données de paiement

Symptôme. Des clients ou votre banque signalent des débits frauduleux dans les jours qui suivent une commande sur votre boutique. Rien n'est visible sur le site.

Pourquoi. Un script inséré dans le tunnel de commande recopie les données saisies dans le formulaire de paiement et les envoie vers un serveur tiers, sans perturber la transaction. La commande aboutit normalement, ce qui explique que ce type d'infection puisse passer inaperçu longtemps.

Sur PrestaShop, l'emplacement d'injection le plus courant est le fichier head.tpl du thème actif, dans themes/<votre-theme>/templates/_partials/ : le code s'y retrouve sur toutes les pages du site, page de paiement comprise. Le script est presque toujours encodé, et la combinaison de atob() avec un envoi par XMLHttpRequest ou fetch() vers un domaine que vous ne reconnaissez pas est la signature à chercher.

Un détail explique pourquoi vous ne verrez jamais rien depuis votre propre navigateur : ces scripts vérifient couramment si un cookie de session administrateur est présent, et se mettent en sommeil dans ce cas. Connecté à votre back office, vous êtes précisément le visiteur que le script évite.

C'est la seule forme de piratage de cette liste qui engage votre responsabilité vis-à-vis de vos clients. Elle relève d'une violation de données personnelles, avec des obligations de notification qui dépassent le cadre technique de cet article : le sujet se traite avec votre prestataire de paiement, et le cas échéant avec un conseil juridique.

Correction.

1. Coupez le tunnel de commande sans attendre, chaque commande supplémentaire expose un client de plus.
2. Comparez les fichiers et modèles du tunnel avec ceux d'origine, y compris les modules de paiement.
3. Inspectez les scripts chargés sur la page de paiement, en particulier ceux hébergés sur un domaine tiers que vous ne reconnaissez pas.
4. Ouvrez head.tpl et les modèles du thème, et comparez-les à ceux de votre thème d'origine : c'est là que le code est le plus souvent posé.
5. Prévenez votre prestataire de paiement, qui dispose de ses propres moyens de contrôle sur les transactions concernées.

Cas 5 : relais de spam par mail

Symptôme. Vos e-mails de confirmation de commande n'arrivent plus, ou arrivent en indésirable. Votre hébergeur signale un envoi massif depuis votre compte, ou une surconsommation de ressources sans explication.

Pourquoi. Un script déposé sur le serveur utilise votre hébergement pour envoyer du courrier en masse. Le domaine et l'adresse IP finissent sur des listes de blocage, ce qui coupe la délivrabilité de tous vos e-mails légitimes, confirmations de commande comprises.

Correction.

1. Demandez à l'hébergeur les logs d'envoi, qui identifient le script émetteur, souvent en une seule requête.
2. Supprimez le script et traitez la porte dérobée associée, décrite au cas 3.
3. Vérifiez ensuite l'état du domaine auprès des principales listes de blocage, et demandez le retrait une fois la source tarie.
4. Contrôlez les enregistrements SPF, DKIM et DMARC du domaine, dont l'absence facilite l'usurpation.

Vos obligations légales

Dès que des données personnelles ont pu être consultées ou copiées, le piratage n'est plus seulement un incident technique : c'est une violation de données au sens du RGPD, et un délai court démarre au moment où vous en prenez connaissance.

Notifier la CNIL sous 72 heures

L'article 33 du RGPD impose de notifier la violation à la CNIL dans les 72 heures suivant sa découverte, sauf si elle n'est pas susceptible d'engendrer un risque pour les personnes concernées. Un vol de données de paiement ou de comptes clients entre clairement dans le champ de la notification. La déclaration se fait en ligne sur le téléservice de notification de la CNIL.

Le délai court à partir du moment où vous avez connaissance de l'incident, pas du moment où l'intrusion a eu lieu. Si tous les éléments ne sont pas encore réunis, la notification peut être faite en plusieurs fois plutôt que d'attendre d'avoir tout compris.

Informer vos clients

L'article 34 impose en plus d'informer les personnes concernées, dans les meilleurs délais, lorsque la violation est susceptible d'engendrer un risque élevé pour leurs droits et libertés. Des coordonnées bancaires captées au moment du paiement relèvent de ce cas. L'information doit être claire sur ce qui s'est passé, sur les données concernées et sur ce que la personne peut faire, à commencer par surveiller ses comptes.

Déposer plainte

Vous êtes victime d'une infraction pénale, et le dépôt de plainte est utile au-delà du principe : il documente l'incident vis-à-vis de vos clients, de votre banque et de votre assureur. Le portail 17cyber.gouv.fr oriente vers le bon interlocuteur, et cybermalveillance.gouv.fr recense les prestataires de remédiation.

Ces trois démarches supposent de savoir ce qui a été touché et depuis quand. C'est exactement ce que détruit un nettoyage fait dans la précipitation, et c'est pourquoi la copie de l'état infecté et les logs d'accès de l'hébergeur doivent être mis de côté avant toute intervention.

Nettoyer la boutique, dans l'ordre

L'ordre compte davantage que les outils employés. Nettoyer les symptômes avant d'avoir fermé la porte d'entrée conduit systématiquement à recommencer.

1. Dater l'intrusion. Les fichiers modifiés et les logs d'accès de l'hébergeur donnent le jour, souvent l'heure. Tout le reste en dépend, à commencer par le choix d'une sauvegarde saine.
2. Fermer le point d'entrée. Version obsolète, module vulnérable, identifiants compromis : sans cette étape, les suivantes sont provisoires.
3. Supprimer les portes dérobées. Par comparaison avec l'archive officielle, sur l'ensemble de l'arborescence.
4. Restaurer les fichiers du coeur. Remplacez-les par ceux de l'archive officielle, en conservant vos dossiers propres : thème, modules, images, fichiers de configuration.
5. Nettoyer la base. Contenus injectés, comptes administrateurs inconnus, entrées de configuration modifiées.
6. Renouveler tous les accès. FTP, SSH, base de données, back office, panel hébergeur, sans exception.
7. Vider les caches, y compris celui d'un éventuel service de cache en amont, qui peut continuer à servir des pages infectées après le nettoyage.
8. Contrôler. Rejouez les six vérifications de la section précédente. Elles doivent toutes être négatives avant de considérer le nettoyage terminé.

Si la boutique tourne sur une version qui ne reçoit plus de correctifs, le nettoyage ne fait que gagner du temps : la faille exploitée reste ouverte, et une autre le sera bientôt. Dans ce cas, la remise à niveau fait partie de la réparation, et la migration vers Prestashop 8 devient le vrai sujet.

Réparer le SEO : désindexer les URLs spam

Après nettoyage du piratage, il faut contrôler l'indexation des milliers de pages créées, cela fait également partie de mon rôle de consultant SEO.

Renvoyer un code 410, pas un 404 ni une redirection

Il est nécessaire de traiter toutes les URL qui ont été prises en considération par Google même si elles n'existent plus. Il faut donc traiter chaque URL par une réponse 410.

Ces URLs partagent presque toujours un motif commun, ce qui permet de les traiter par lot plutôt qu'une par une, avec une règle dans le .htaccess :

RedirectMatch 410 ^/(.*)(viagra|cialis|pharmacy|replica|casino)(.*)$

Le motif est à construire à partir de votre propre liste d'URLs indexées, jamais copié tel quel. Un motif trop large peut faire disparaître des pages légitimes de votre catalogue, et l'erreur ne se voit pas immédiatement.

Lever une action manuelle

Si vous n'avez pas réagi assez vite ou si le piratage est trop violent et rapide, il se peut alors que vous preniez une pénalité manuelle. C'est un cas critique, qu'il va falloir résoudre et qui peut fortement pénaliser le référencement de votre boutique Prestashop.

Suivre la disparition dans le temps

La désindexation n'est pas instantanée : Google doit repasser sur chaque URL pour constater le 410. Sur une attaque qui a généré des milliers de pages, cela s'étale sur plusieurs semaines, les URLs les plus profondes étant les dernières traitées.

Éviter que ça se reproduise

Un site nettoyé sans que la cause soit traitée se réinfecte, parfois en quelques jours. Cinq points ferment l'essentiel des portes d'entrée.

• Rester sur une version maintenue. Le support de PrestaShop 1.6 s'est arrêté le 30 juin 2019, celui de la 1.7 le 10 juin 2025. Sur ces versions, les failles publiées depuis ne sont pas corrigées, et une faille publique est exploitée automatiquement, sans que votre boutique ait été ciblée en particulier.
• Maintenir une version de PHP supportée. Une version de PHP en fin de vie ne reçoit plus de correctifs de sécurité, indépendamment de PrestaShop.
• Supprimer les modules inutilisés au lieu de les désactiver. Un module désactivé reste présent sur le disque, et son code reste atteignable.
• Limiter les accès. Un compte administrateur par personne réellement concernée, supprimé au départ de celle-ci, et un dossier d'administration renommé.
• Surveiller l'index, pas seulement les fichiers. Un spam SEO n'a aucun effet visible sur la boutique : il se voit dans Search Console et dans les résultats de recherche, souvent des semaines avant d'être remarqué autrement.

Ce dernier point est celui qui change le plus l'issue. Une infection repérée dans la semaine se répare en quelques jours ; la même infection découverte six mois plus tard laisse un index saturé de pages spam et des positions à reconstruire. Un suivi régulier de ce que Google indexe fait donc plus pour la sécurité d'une boutique que n'importe quel nettoyage d'urgence, et c'est l'un des angles que je couvre en accompagnement SEO.