Boutique PrestaShop piratée : nettoyer, trouver la porte d’entrée, la refermer

Une boutique PrestaShop piratée se traite dans cet ordre : copier l’état des fichiers et des journaux, retirer le code malveillant, trouver l’accès par lequel il est entré, puis seulement rouvrir. Google range la correction de la vulnérabilité parmi les conditions préalables à son réexamen. La page « Request a review » de web.dev annonce des délais d’environ un jour à plusieurs semaines, selon la nature de l’alerte.

• Quatre signes permettent de soupçonner un site PrestaShop piraté
• Les preuves se copient avant le premier nettoyage
• Le code malveillant se cherche dans les fichiers, puis dans la base de données
• La porte d’entrée d’une boutique PrestaShop se cherche d’abord dans les avis publiés
• Tous les mots de passe et les identifiants d’accès se changent avant la remise en ligne
• Google retire l’avertissement après un réexamen qui décrit chaque correction
• La CNIL se notifie dans les 72 heures quand la fuite expose des personnes
• Un nettoyage se prouve par des livrables écrits
• Deux gestes renvoient la boutique vers la réinfection
• Sources consultées
• Foire aux questions

Quatre signes permettent de soupçonner un site PrestaShop piraté

Le premier est une redirection : le visiteur arrive sur une autre adresse que la vôtre. Le deuxième est un formulaire de paiement que personne n’a écrit. En juillet 2022, l’éditeur de PrestaShop décrivait des attaquants qui injectaient un faux formulaire de paiement dans la page de commande. Le troisième est une alerte de Google, dans le rapport « Security Issues » (problèmes de sécurité) de la Search Console. Le dernier est une page défigurée, dont le pirate a modifié l’apparence.

Pour le deuxième signe, ouvrez la boutique en navigation privée et allez jusqu’à la page de paiement avec un produit au panier : un formulaire inconnu peut s’y voir à l’œil nu ; son absence ne prouve pas que la boutique est saine.

Les preuves se copient avant le premier nettoyage

La fiche réflexe sur la défiguration de site, de Cybermalveillance.gouv.fr avec le ministère de l’Intérieur et l’ANSSI, demande d’alerter l’hébergeur, de récupérer les journaux et de copier intégralement la machine attaquée. Elle ajoute d’identifier les éléments sensibles copiés ou détruits.

Sur un hébergement mutualisé, la machine n’est pas la vôtre : demandez à l’hébergeur les journaux d’accès du serveur web, une copie des fichiers et une copie de la base de données. Sans journaux, l’accès initial se devine au lieu de se démontrer (déduction).

Le code malveillant se cherche dans les fichiers, puis dans la base de données

L’écran Paramètres avancés > Informations (Advanced Parameters > Information) contient une « Liste des fichiers modifiés ». La documentation de PrestaShop 8 la décrit comme une comparaison avec l’installation d’origine, qui affiche aussi les modules et thèmes ajoutés. C’est un point de départ : la page ne dit pas qu’elle signale un fichier déposé par un pirate.

Le code peut aussi vivre dans la base. En 2022, l’éditeur demandait de désactiver le cache Smarty (le moteur de gabarits) stocké dans la base de données MySQL, par lequel du code pouvait être injecté. La version 1.7.8.7 a durci ce cache.

La porte d’entrée d’une boutique PrestaShop se cherche d’abord dans les avis publiés

Comparez la version du cœur et celle de chaque module aux avis de l’éditeur et de l’association Friends of Presta. En 2022, la chaîne d’attaque visait les boutiques sur PrestaShop 1.6.0.10 et suivantes sujettes aux injections SQL, et le module Wishlist en versions 2.0.0 à 2.1.0. L’éditeur ne pouvait pas garantir que ce soit la seule voie. La méthode pour savoir si un avis vous concerne figure dans la page sur les correctifs de failles.

Les mots de passe faibles ou laissés par défaut sont une autre entrée : la fiche réflexe les cite en prévention, avec les tentatives répétées visibles dans les journaux du serveur.

La branche installée compte : sur une 1.7, un avis du cœur publié après le 10 juin 2025 n’a plus de correctif de l’éditeur (déduction), et la 1.6 dépend de correctifs de bénévoles (annonce de 2019).

Décrire mon besoin →

Tous les mots de passe et les identifiants d’accès se changent avant la remise en ligne

La fiche réflexe demande de corriger les failles et de changer tous les mots de passe avant de remettre le site en ligne. Pour une boutique PrestaShop, la liste comprend :

• les comptes employés du back-office, à relire dans le menu Équipe (Team), compte créé par un inconnu compris ;
• le compte de l’hébergeur et les accès FTP ou SSH, c’est-à-dire les accès aux fichiers du serveur ;
• le mot de passe de la base de données ;
• les identifiants d’API des modules de transport et de paiement.

Changez-les même si le module n’est pas la porte d’entrée : l’avis de Friends of Presta sur upsshipping le demande pour l’API du transporteur exposée.

Google retire l’avertissement après un réexamen qui décrit chaque correction

Le rapport « Security Issues » distingue trois familles d’alertes d’après l’aide de la Search Console ; les délais viennent de la page « Request a review » de web.dev.

Avant la demande, la propriété du site doit être vérifiée dans la Search Console, la vulnérabilité corrigée et le site remis en ligne. Les pages à contrôler ne doivent être ni bloquées par le fichier robots.txt (la liste des pages interdites aux robots) ni porter une balise noindex (l’ordre de ne pas les indexer). La demande décrit les actions menées, par catégorie de spam pour un site piraté.

Une demande prématurée prolonge la période d’alerte (web.dev) et ne se renvoie pas avant la décision (aide). Si le site est jugé propre, les avertissements disparaissent sous 72 heures.

La CNIL se notifie dans les 72 heures quand la fuite expose des personnes

Selon l’article 33 du règlement général sur la protection des données (RGPD), le responsable du traitement notifie l’autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance. Seule exception : une violation non susceptible d’engendrer un risque pour les personnes. Il documente aussi toute violation. Une boutique détient des noms, des adresses et des commandes. Un faux formulaire de paiement sur la commande pose en plus la question des données saisies par les clients.

Un nettoyage se prouve par des livrables écrits

Exigez par écrit la chronologie : première trace, accès probable, ou « indéterminé » avec la raison (journaux absents, intrusion ancienne). Exigez la liste des fichiers retirés ou remplacés, celle des enregistrements modifiés dans la base, et la version de PrestaShop et de chaque module avant et après. Ajoutez la liste des mots de passe et clés changés, sans leur valeur, le test du parcours de commande jusqu’au paiement et le texte du réexamen déposé auprès de Google, s’il y a eu une alerte.

Faites écrire qui paie si la boutique est piratée de nouveau par la même porte, et qui paie si l’intervention casse la boutique : retour arrière depuis la copie prise au départ.

Le devis varie avec le nombre de modules, le volume de fichiers à comparer, la présence de journaux et d’une sauvegarde saine datée, l’alerte Google à lever et l’urgence. Comparez des périmètres écrits, pas des totaux.

Un audit de sécurité après nettoyage vérifie ensuite que la porte est fermée.

Décrire mon besoin →

Deux gestes renvoient la boutique vers la réinfection

Restaurer la dernière sauvegarde sans connaître la date de la première trace : si la copie est postérieure à l’intrusion, elle contient le code malveillant. Les sauvegardes et la reprise ont leur propre page.

Nettoyer sans relire les comptes : un compte employé créé par le pirate garde son accès après le retrait des fichiers (scénario).

Le message du formulaire de cette page peut porter la date du premier symptôme, votre version de PrestaShop et le type d’alerte reçu ; un mot de passe ne s’y écrit jamais.

Sources consultées

• Google, web.dev, « Request a review », consulté le 14 octobre 2026.
• Google, aide Search Console, « Security issues report », consulté le 14 octobre 2026.
• Cybermalveillance.gouv.fr, ministère de l’Intérieur et ANSSI, fiche réflexe « La défiguration », version V230417, consulté le 14 octobre 2026.
• PrestaShop, « Major Security Vulnerability on PrestaShop Websites », 22 juillet 2022, mis à jour le 25 juillet 2022, consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de PrestaShop 8, « Informations de configuration » et « Maintenance de la boutique », consulté le 14 octobre 2026.
• Friends of Presta, avis de sécurité du module upsshipping (CVE-2026-39079), consulté le 14 octobre 2026.
• Règlement (UE) 2016/679 (RGPD), article 33, Journal officiel de l’Union européenne, L 119 du 4 mai 2016, consulté le 14 octobre 2026.

Foire aux questions

Une mise à jour de PrestaShop suffit-elle à nettoyer une boutique piratée ?

L’article de l’éditeur de juillet 2022 ne le dit pas : la mise à jour doit protéger contre les injections SQL connues et exploitées, et il suggère de faire appel à un spécialiste pour un audit complet, qui vérifie qu’aucun fichier n’a été modifié et qu’aucun code malveillant n’a été ajouté.

Le fichier blm.php est-il le seul signe à chercher ?

Non. L’éditeur le décrit comme un schéma récurrent de 2022, mais précise que les attaquants peuvent utiliser un autre nom de fichier. Ne pas retrouver ce motif dans vos journaux ne prouve pas que la boutique est saine.

Le mode maintenance de PrestaShop coupe-t-il l’exposition ?

Il ferme la boutique aux visiteurs : l’option « Activer la boutique » la désactive, et « IP de maintenance » laisse passer vos adresses. La page « Maintenance de la boutique » de la documentation de PrestaShop 8 précise que le service web reste actif, et un fichier déposé à la racine ne passe pas par PrestaShop (déduction) : l’hébergeur, lui, peut couper l’accès.

Faut-il porter plainte après un piratage de boutique ?

La fiche réflexe sur la défiguration recommande de déposer plainte au commissariat de police ou à la gendarmerie, ou d’écrire au procureur de la République, en fournissant toutes les preuves en votre possession.

Le contenu piraté disparaît-il des résultats de Google ?

Google indique chercher à tenir le contenu piraté hors des résultats de recherche. L’aide de la Search Console annonce un réexamen de quelques jours à quelques semaines, sans chiffrer le retour des positions : vérifiez vos pages ensuite.