En bref : en octobre 2026, pendant l'audit de migration d'une boutique PrestaShop 1.6 vers PrestaShop 9.2, nous avons découvert que le site était compromis depuis au moins août 2024. Au total, onze fichiers avaient été ajoutés ou modifiés par des pirates, dont un qui volait les mots de passe du back-office. Voici ce que nous avons trouvé, comment, ce que nous avons corrigé, et pourquoi la migration prévue début janvier 2027 règle le problème à la racine.
Cette boutique est celle d'un commerce indépendant, avec un magasin physique et plus de 20 000 fiches clients en ligne. La gérante est une nouvelle cliente : elle nous a confié la migration de son PrestaShop 1.6 cet été. Nous racontons son cas sans la nommer, parce qu'il ressemble à celui de beaucoup de boutiques restées en 1.6 : tout semble fonctionner, les commandes tombent, et personne ne regarde ce qui se passe dans les fichiers.
Le point de départ : une boutique en PrestaShop 1.6 qui « marche »
Lors du premier rendez-vous, nous avons fait un état des lieux technique. La boutique tournait sous PrestaShop 1.6.1.11 avec PHP 7.0. Deux faits suffisent à résumer le risque :
- PrestaShop a arrêté la maintenance officielle de la branche 1.6 le 30 juin 2019. Ensuite, seuls des bénévoles ont publié quelques correctifs critiques. La boutique n'avait même pas les dernières versions de sécurité de la 1.6 (1.6.1.21 à 1.6.1.24, publiées en 2018 et 2019).
- PHP 7.0 ne reçoit plus aucun correctif depuis le 10 janvier 2019.
Nous l'avons expliqué à la cliente en ces termes : chaque jour sans migration est un jour où une faille connue reste ouverte, et le jour où quelqu'un l'exploite, on ne le voit pas forcément. Elle a choisi de migrer vers PrestaShop 9.2, avec une mise en ligne prévue entre le 1er et le 5 janvier 2027, avant les soldes d'hiver. Nous lui avons aussi dit franchement que si la recette n'était pas satisfaisante mi-décembre, il serait plus prudent de faire les soldes sur l'ancien site et de basculer juste après.
Pour comprendre pourquoi une version en fin de vie est un risque concret, voir aussi notre article sur PrestaShop 1.6 en fin de vie.
Comment le piratage a-t-il été découvert ?
Le piratage a été découvert pendant la préparation de la migration, pas par un symptôme visible. La boutique fonctionnait normalement. C'est l'analyse fichier par fichier de la copie de référence, prise avant tout travail, qui a fait apparaître un module que personne n'avait installé.
Une migration propre commence par une copie complète du site actuel : fichiers, base de données et journaux, avec une empreinte (SHA-256) de chaque fichier. Cette copie sert de référence et nous permet de travailler sans toucher à la boutique en ligne.
En analysant cette copie, nous avons repéré un module que personne n'avait installé : psanalyticsenhancer. Son nom imitait un outil de statistiques officiel. Il avait été déposé le matin même et contenait deux portes dérobées.
Une porte dérobée (ou backdoor) est un petit fichier qui permet à un pirate d'exécuter n'importe quelle commande sur le serveur, sans passer par le back-office. Elle ne change rien à l'affichage du site : le commerçant ne voit rien.
Les journaux du serveur ont ensuite montré la suite. Le soir du même jour, pendant environ 40 minutes, depuis un serveur VPN situé à l'étranger, le pirate a :
- appelé la porte dérobée une quarantaine de fois ;
- installé un outil d'administration de base de données (Adminer) et s'est connecté avec les identifiants techniques de la boutique, lus dans le fichier de configuration ;
- consulté la table des comptes d'administration, puis la table des clients jusqu'à la dernière page ;
- ouvert le back-office avec la session de la gérante et consulté des pages de commandes ;
- supprimé ses outils et les deux portes dérobées du faux module pour effacer ses traces.
Nous n'avons trouvé aucune trace de téléchargement massif de la base clients (pas d'export, pas de réponse assez volumineuse). En revanche, la consultation des coordonnées des clients est avérée. La boutique ne stocke aucune donnée bancaire : les paiements passent par les pages sécurisées des banques.
Par où le pirate est-il entré ?
Le faux module a été déposé depuis la connexion Internet du magasin, à une heure où la gérante travaillait normalement dans le back-office. Aucune requête web de dépôt, aucune connexion FTP ce jour-là. La même connexion utilisait encore un ancien poste sous Windows 7 pour lire les e-mails.
L'hypothèse la plus probable : ce poste, qui ne reçoit plus de mises à jour depuis des années, était infecté et a servi à voler la session ou les identifiants. C'est une hypothèse, pas une certitude. Nous avons demandé à la cliente de le débrancher et de faire vérifier tous les postes du magasin. Un site peut être parfaitement à jour et quand même se faire voler ses accès par le poste qui s'y connecte.
Depuis quand la boutique était-elle piratée ?
Depuis au moins août 2024, soit 14 mois avant l'attaque d'octobre 2026. Les plus anciennes portes dérobées dormaient dans le paiement par virement et dans la newsletter. D'autres ont été ajoutées en décembre 2024 et en mars 2025, malgré un nettoyage partiel fait entre-temps par un tiers.
Chronologie
| Date | Événement |
|---|---|
| août 2024 | portes dérobées dans les modules de paiement par virement et de newsletter |
| novembre 2024 | nettoyage partiel par un outil tiers, qui ne retire pas tout |
| décembre 2024 | deux nouvelles portes dérobées, dont une dans un fichier officiel du cœur |
| mars 2025 | webshell complet déposé à la racine |
| été 2026 | premier rendez-vous, risques de la version 1.6 expliqués, migration décidée |
| octobre 2026, matin | faux module « statistiques » déposé |
| octobre 2026, soir | consultation de la base clients, vol d'identifiants, voleur de mots de passe posé, traces effacées |
| le lendemain | preuves conservées, portes dérobées retirées, accès changés |
| quelques jours plus tard | contrôle de suivi, fichiers antidatés retirés |
| début janvier 2027 | mise en ligne prévue de la boutique PrestaShop 9.2 reconstruite à neuf |
Les fichiers trouvés
Une fois l'attaque du jour comprise, nous avons comparé chaque fichier du site avec l'archive officielle de PrestaShop 1.6.1.11, soit 3 105 fichiers PHP, JavaScript et .htaccess. Résultat : la boutique était compromise bien avant cette attaque.
| Fichier | Déposé | Rôle |
|---|---|---|
modules/bankwire/controllers/front/validation.php | août 2024 | porte dérobée cachée dans la validation du paiement par virement |
modules/blocknewsletter/controllers/front/verification.php | août 2024 | porte dérobée dans le module newsletter |
images.inc.php (racine) | décembre 2024 | exécution de code envoyé par le pirate, ajoutée au milieu d'un fichier officiel |
modules/statscarrier/translations/ar.php | décembre 2024 | même porte dérobée, déguisée en fichier de traduction |
indexx.php (racine) | mars 2025 | webshell obfusqué de 68 Ko, c'est-à-dire une interface complète de prise de contrôle du serveur |
Nous avons aussi trouvé à la racine deux scripts de nettoyage d'un éditeur tiers, datés de novembre 2024. Quelqu'un avait donc déjà « nettoyé » le site à l'époque, mais sans tout retirer. Ces anciennes portes dérobées n'avaient pas été appelées dans les journaux disponibles : elles dormaient, prêtes à servir.
Le site de préproduction, hébergé sur le même compte, a été contrôlé de la même façon : aucune de ces signatures.
Notre intervention : preuves, neutralisation, accès coupés
La migration ne pouvait pas avancer sur un site compromis. Avec l'accord de la cliente, nous avons pris en charge la mise en sécurité de la boutique en ligne, dans cet ordre :
- Conserver les preuves avant de toucher à quoi que ce soit. Copie de chaque fichier malveillant hors du répertoire web, empreintes SHA-256, horodatage. Si la cliente veut porter plainte, le dossier est prêt.
- Neutraliser. Les fichiers ajoutés par le pirate ont été déplacés en quarantaine. Les fichiers officiels modifiés ont été remplacés par leur version d'origine, et nous avons vérifié que leur empreinte correspond à l'archive PrestaShop.
- Tester. Chaque porte dérobée retirée renvoie une erreur 404. Un envoi de test sur l'ancienne porte de
images.inc.phpn'exécute plus rien. - Couper les accès volés. Nouveaux mots de passe pour les quatre comptes du back-office, les deux bases de données et les comptes FTP. Changer le mot de passe d'un compte PrestaShop 1.6 invalide aussi les sessions déjà ouvertes avec l'ancien.
- Bloquer l'adresse IP utilisée par le pirate. C'est utile mais secondaire : un VPN en change facilement. Pour filtrer durablement les attaques, il faut un pare-feu applicatif réglé pour PrestaShop.
- Vérifier que la boutique fonctionne : accueil, catégories, fiches produit, commande, back-office.
Comment repérer les fichiers antidatés par un pirate ?
Un pirate peut changer la date de modification d'un fichier pour qu'il paraisse ancien. Il ne peut pas changer sa date de changement d'état (ctime sous Linux). Rechercher tous les fichiers dont le ctime tombe pendant l'attaque fait ressortir ses dépôts, même s'ils affichent une date de 2024.
Quelques jours après l'intervention, un contrôle de suivi complet a été mené avec une autre méthode : comparaison de chaque fichier avec la copie de référence prise avant l'attaque, et recherche par date système. Il a mis au jour cinq fichiers supplémentaires, posés par le pirate le soir de l'attaque, en sept minutes :
- un fichier
footer.phpajouté dans le dossier d'administration, chargé par une ligne ajoutée dansindex.php. C'était un voleur d'identifiants : à chaque connexion au back-office, il vérifiait l'e-mail et le mot de passe saisis, puis les envoyait versgoogleeanalytics.com, un domaine qui imite Google Analytics ; - trois portes dérobées ajoutées à l'intérieur de fichiers de modules existants (liste de souhaits, bandeau cookies) ou dans un script de mise à jour de module.
Pourquoi ces fichiers sont-ils si difficiles à repérer ? Parce que le pirate avait antidaté leur date de modification à 2024 pour qu'ils passent pour d'anciens fichiers, et parce que les fichiers de modules tiers ne figurent pas dans l'archive officielle de PrestaShop : une simple comparaison avec les fichiers du CMS ne les signale pas.
Ce qui les a trahis : la date de changement d'état du fichier (ctime sous Linux), qu'on ne peut pas modifier à la main comme la date de modification. Une recherche de tous les fichiers dont le ctime tombe dans la fenêtre de l'attaque a donné exactement ces cinq fichiers, et aucun autre. La comparaison avec notre copie de référence a confirmé chaque modification.
Les cinq fichiers ont été retirés avec la même procédure (preuves, quarantaine, restauration, tests). Un voleur d'identifiants rappelle une règle simple : changer les mots de passe ne sert que si plus rien sur le serveur ne peut les intercepter. On change donc les accès après le retrait complet, et on les transmet par téléphone, jamais par e-mail.
La méthode à retenir : après une compromission, on ne se contente pas de comparer avec les fichiers officiels du CMS. On compare aussi avec une copie complète prise avant l'intervention, on cherche par ctime et pas seulement par date de modification, et on refait un contrôle quelques jours plus tard.
Faut-il prévenir la CNIL après le piratage d'une boutique ?
Le pirate a consulté des coordonnées de clients : noms, adresses, e-mails, téléphones. Pour le RGPD, c'est une violation de données personnelles. La CNIL demande au responsable du traitement, ici la commerçante, de la notifier au plus tard 72 heures après en avoir pris connaissance si elle présente un risque pour les personnes, et d'informer les personnes en cas de risque élevé.
Notre rôle n'est pas de décider à la place du commerçant, mais de lui donner les faits pour décider : ce qui a été consulté, ce qui ne l'a pas été, les preuves, la chronologie. Nous lui avons remis un dossier complet qui peut servir à une notification ou à une plainte. Si vous êtes dans ce cas, la procédure est sur le site de la CNIL.
Pourquoi la migration vers PrestaShop 9.2 règle le problème à la racine
Nettoyer un PrestaShop 1.6 remet le site en état, mais les failles qui ont permis l'intrusion restent. La migration change la donne pour plusieurs raisons :
- Aucun fichier de l'ancien site n'est repris. La boutique 9.2 est installée à neuf : cœur, thème et modules. Les portes dérobées cachées dans les fichiers ne peuvent pas suivre.
- Les données sont contrôlées avant import. Nous avons analysé les 460 colonnes de texte migrées à la recherche de code actif (scripts, iframes). Le seul contenu actif trouvé : des vidéos YouTube légitimes dans des fiches produits.
- Le serveur change de génération. PrestaShop 9 fonctionne avec PHP 8.1 et plus. Plusieurs des portes dérobées trouvées reposaient sur la fonction PHP
create_function, supprimée depuis PHP 8.0 : elles ne fonctionneraient même plus. - La boutique redevient maintenable. Une version supportée reçoit des correctifs de sécurité, et une maintenance peut les appliquer au fil de l'eau.
D'ici janvier, la boutique actuelle reste sous surveillance. La migration à blanc est déjà faite : chiffre d'affaires identique au centime sur toutes les années, et les clients garderont leur mot de passe actuel. Notre page migration vers PrestaShop 9 détaille la méthode.
Et la faille PHP « php2shell » d'octobre 2026 ?
Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques, CVE-2026-109618 et CVE-2026-109619, surnommées « php2shell » et notées 9,2 sur 10. Elles permettent d'exécuter du code sur le serveur, donc de déposer un webshell, avec une simple requête et sans être connecté, avant même que PrestaShop ne s'exécute.
Un webshell est un fichier qui donne au pirate une interface de commande sur le serveur, comme le indexx.php trouvé dans notre cas. Avec php2shell, le pirate n'a même plus besoin d'une faille de PrestaShop ou d'un module pour l'installer : la faille est dans PHP lui-même, et mettre à jour PrestaShop ne la corrige pas.
| Version de PHP | Situation |
|---|---|
| 8.2, 8.3, 8.4, 8.5 | corrigées en 8.2.35, 8.3.36, 8.4.27 et 8.5.12 |
| 7.4, 8.0, 8.1 | plus de version officielle ; le projet PHP fournit seulement des correctifs à compiler soi-même |
| 7.3 et antérieures (dont PHP 7.0) | aucun correctif du projet PHP ; seuls certains hébergeurs ou éditeurs proposent une version corrigée |
Une boutique PrestaShop 1.6 tourne presque toujours sur PHP 5.6, 7.0 ou 7.1, car elle ne fonctionne pas avec les versions récentes. Elle dépend donc entièrement de son hébergeur pour ce correctif. Sur la boutique de notre cas, l'hébergeur avait recompilé sa version PHP 7.0 le jour même de l'annonce. Ce n'est pas le cas partout : demandez à votre hébergeur s'il a appliqué le correctif à votre version de PHP, ou faites vérifier l'exposition de votre boutique aux failles PrestaShop et PHP.
Le projet PHP le dit clairement : régler session.upload_progress.enabled=0 ferme certains chemins d'attaque, mais seule la mise à jour protège réellement. Une boutique PrestaShop 9 accepte PHP 8.4 ou 8.5, des versions maintenues qui ont reçu ce correctif dès sa publication. À noter : PHP 8.2 ne recevra plus de correctifs après le 31 décembre 2026, ce qui compte au moment de choisir la version pour une migration.
Comment savoir si votre boutique PrestaShop est piratée ?
Un piratage PrestaShop ne se voit souvent pas : la boutique tourne et les commandes arrivent. Six contrôles simples permettent de repérer les signes les plus fréquents. Aucun ne remplace une comparaison complète des fichiers, mais un seul signal positif justifie un diagnostic.
| Contrôle | Ce qui doit alerter |
|---|---|
Liste des modules (dossier modules/) | un module que vous n'avez jamais installé, surtout au nom « officiel » ou « analytics » |
| Racine du site | des fichiers PHP inconnus : indexx.php, noms aléatoires, adminer.php |
| Dossier d'administration | un fichier ajouté (par exemple footer.php) ou un index.php qui charge un fichier inconnu |
| Comptes du back-office | un employé que vous ne connaissez pas, ou des connexions à des heures où personne ne travaillait |
| Version | PrestaShop 1.6 ou 1.7, PHP inférieur à 8.1 |
| Postes du magasin | un ordinateur sous Windows 7 ou sans antivirus qui sert à se connecter au site ou à lire les e-mails |
Si un de ces points vous inquiète, ne supprimez rien vous-même : vous effaceriez les preuves et vous risquez d'en oublier. Notre procédure complète est décrite dans Boutique PrestaShop piratée : la procédure de nettoyage.
En résumé
- Une boutique PrestaShop 1.6 peut être compromise pendant plus d'un an sans aucun signe visible.
- L'attaque d'octobre 2026 a été détectée parce que la migration commence par une copie complète et vérifiée du site.
- Un pirate soigneux antidate ses fichiers : la recherche doit aussi porter sur le
ctime, et un contrôle de suivi est indispensable. - Le poste de travail qui se connecte au back-office fait partie de la surface d'attaque.
- Depuis php2shell (octobre 2026), une vieille version de PHP suffit à exposer la boutique, quel que soit l'état de PrestaShop.
- Nettoyer remet en état, migrer vers une version supportée supprime la cause.
Votre boutique tourne encore en PrestaShop 1.6 ou 1.7, ou vous avez un doute sur un fichier ? Envoyez-nous l'adresse du site : nous faisons un diagnostic de sécurité gratuit, et en cas de piratage avéré, nous intervenons sur devis écrit (nettoyage d'une boutique PrestaShop piratée). Pour la suite, la maintenance PrestaShop applique les correctifs au fil de l'eau.
Sources
- PrestaShop, « 1.6.1.x: what's next », blog des développeurs, 4 juillet 2019 : build.prestashop-project.org (consulté le 24 octobre 2026)
- PrestaShop, prérequis système de PrestaShop 9 : devdocs.prestashop-project.org (consulté le 24 octobre 2026)
- PHP, annonce de sécurité du 21 octobre 2026 (CVE-2026-109618, CVE-2026-109619) : php.net (consulté le 24 octobre 2026)
- PHP, branches non supportées : php.net/eol.php (consulté le 24 octobre 2026)
- PHP, documentation de
create_function: php.net (consulté le 24 octobre 2026) - CNIL, « Notifier une violation de données personnelles » : cnil.fr (consulté le 24 octobre 2026)
- Cybermalveillance.gouv.fr, « Défiguration de site Internet, que faire ? » : cybermalveillance.gouv.fr (consulté le 24 octobre 2026)
