Skimmer PrestaShop 2026 : le test en 5 minutes pour détecter le malware invisible

Depuis janvier 2026, une campagne de digital skimmers cible les boutiques PrestaShop. Le piège le plus dangereux : le malware se désactive quand un administrateur est connecté. Vous testez votre tunnel de commande depuis le back-office, tout semble normal — vos clients, eux, voient un faux formulaire de paiement.

Dans ce guide exhaustif, vous obtenez le protocole que j’applique après 50+ audits de sécurité :

• Le test de détection en 5 minutes (navigation privée + mobile)
• Les fichiers à inspecter en priorité (head.tpl, modules suspects)
• Le protocole d’urgence si votre boutique est compromise
• Les obligations CNIL sous 72 heures
• Une checklist de prévention à imprimer

Si vous gérez une boutique PrestaShop et que vous n’avez pas audité votre tunnel de paiement ce mois-ci, considérez ce sujet comme urgent — pas théorique. Besoin d’un regard externe ? Demandez un audit sécurité express ou consultez mon accompagnement freelance PrestaShop.

Sommaire

1. Alerte officielle PrestaShop : où en est-on en juillet 2026 ?
2. Comment fonctionne le skimmer 2026
3. Le test en 5 minutes : protocole d’audit
4. Où chercher dans les fichiers (checklist FTP/SSH)
5. Signes d’alerte côté clients et back-office
6. Protocole d’urgence si votre boutique est compromise
7. Nettoyage : pourquoi supprimer le script ne suffit pas
8. Obligations légales : CNIL, clients, plainte
9. Prévention : les 7 réflexes qui bloquent 90 % des attaques
10. PrestaShop 1.7 et 8 : qui est le plus exposé ?
11. Combien coûte une boutique skimmée vs un audit préventif ?
12. Ma checklist express à imprimer
13. Questions / réponses
14. Conclusion

1. Alerte officielle PrestaShop : où en est-on en juillet 2026 ?

Depuis janvier 2026, PrestaShop a identifié et alerté l’écosystème sur une campagne de digital skimmers ciblant les boutiques en ligne. En février, l’éditeur a envoyé un email à l’ensemble des marchands pour recommander une vérification immédiate. Le Help Center PrestaShop confirme le mode opératoire : un script malveillant injecté dans le thème actif remplace les boutons de paiement légitimes par des boutons frauduleux, redirigeant vos clients vers un formulaire contrefait.

Des établissements bancaires ont relayé l’alerte auprès de leurs clients e-commerçants dès fin février 2026. Si vous gérez une boutique PrestaShop et que vous n’avez pas audité votre tunnel de commande depuis, considérez que le sujet est urgent — pas théorique.

2. Comment fonctionne le skimmer 2026 (et pourquoi c’est différent)

Un digital skimmer (ou Magecart) est un JavaScript injecté dans votre boutique. Contrairement à un ransomware visible, il opère en silence : vos pages semblent normales, votre back-office aussi, mais les cartes bancaires de vos clients sont capturées en temps réel.

La campagne 2026 se distingue par des mécanismes d’évasion avancés :

• Le script détecte la présence d’un cookie de session administrateur et se désactive automatiquement.
• Résultat : vous passez une commande test connecté en admin, tout semble parfait — vos clients voient un faux formulaire de paiement.
• Certaines variantes ne s’activent qu’une visite sur deux, rendant le bug intermittent et difficile à reproduire.

Le vecteur d’injection le plus documenté : une balise <script> ajoutée dans themes/votre_theme/templates/_partials/head.tpl. L’attaquant a donc eu un accès en écriture sur votre serveur (FTP compromis, mot de passe faible, module vulnérable, compte admin backdoor).

3. Le test en 5 minutes : protocole que j’utilise en audit

Ne testez jamais uniquement connecté au back-office. C’est l’erreur n°1 qui fait passer des boutiques compromises sous les radars pendant des semaines.

1. Déconnectez-vous complètement du back-office PrestaShop (ou utilisez un autre navigateur).
2. Ouvrez une fenêtre de navigation privée.
3. Depuis un réseau différent si possible (4G mobile plutôt que le Wi-Fi du bureau), accédez à votre boutique.
4. Ajoutez un produit au panier et avancez jusqu’à la page de commande / paiement.
5. Inspectez visuellement : les boutons de paiement ont-ils un libellé, un style ou un ordre inhabituel ? Y a-t-il une redirection vers un domaine que vous ne reconnaissez pas ?
6. Clic droit → Afficher le code source (ou Inspecter). Recherchez (Ctrl+F) : atob(, XMLHttpRequest, Function(, des domaines inconnus, des scripts obfusqués.
7. Comparez avec une capture d’écran archivée de votre tunnel de commande sain, ou avec une boutique de référence sur la même version PrestaShop.

Si un élément vous semble anormal : passez immédiatement la boutique en mode maintenance et coupez les moyens de paiement actifs dans le back-office (Modules → Paiement). Chaque commande qui passe expose une carte bancaire.

4. Où chercher dans les fichiers (checklist FTP/SSH)

Le nettoyage commence par un inventaire systématique. Voici les emplacements que je contrôle en premier sur chaque audit post-skimmer :

1. themes/[theme_actif]/templates/_partials/head.tpl — injection la plus fréquente.
2. themes/[theme_actif]/templates/_partials/footer.tpl et javascript.tpl.
3. themes/[theme_actif]/templates/checkout/_partials/ — templates du tunnel de commande.
4. modules/*/views/js/ — JavaScript des modules tiers, surtout ceux touchant au paiement.
5. override/ — overrides PHP pouvant injecter du contenu.
6. img/ et upload/ — parfois utilisés pour héberger des scripts déguisés.
7. Base de données : table ps_configuration (clés CUSTOM_JS, HTML hooks), pages CMS, ps_hook_module.

Recherchez aussi les modules mloader et simplefilemanager dans /modules/ — leur présence est un indicateur de compromission signalé par PrestaShop. Tri des fichiers par date de modification récente : tout fichier touché sans intervention de votre équipe mérite une analyse.

Pour le contexte modules et failles connues, consultez mon guide modules PrestaShop 2026 et ma politique de sécurité thèmes et modules.

5. Signes d’alerte côté clients et back-office

Au-delà du test technique, certains signaux métier doivent déclencher une investigation immédiate :

• Clients signalant une redirection étrange ou un paiement refusé alors que la commande semble validée.
• Augmentation des abandons panier sur l’étape paiement sans changement marketing.
• Alertes de votre prestataire de paiement (Stripe, PayPal, Payplug).
• Notification de votre banque ou hébergeur ; pour ma part je travaille avec et je recommande ces hébergeurs de qualité
• Nouveaux comptes administrateurs que vous n’avez pas créés.
• Modules installés que vous ne reconnaissez pas.
• Pics de trafic depuis des IPs étranges sur /order ou /paiement.

Le skimmer peut persister en base de données même après suppression du script dans head.tpl — d’où l’importance d’un nettoyage complet, pas d’un simple delete.

6. Protocole d’urgence si votre boutique est compromise

1. Mode maintenance immédiat — back-office ou fichier .maintenance à la racine si le BO est inaccessible.
2. Désactiver tous les modules de paiement actifs.
3. Demander à l’hébergeur de conserver les logs d’accès et d’erreur des 30 derniers jours (forensic).
4. Sauvegarder l’état actuel (fichiers + BDD) avant toute modification — preuve pour plainte et CNIL.
5. Changer TOUS les mots de passe : back-office, FTP/SFTP, SSH, base de données, panel hébergeur, emails associés, clés API de paiement.
6. Supprimer les comptes admin inconnus (Paramètres avancés → Équipe → Employés).
7. Désinstaller physiquement (supprimer le dossier) tout module suspect — désactiver ne suffit pas.
8. Ne remettez pas en ligne tant qu’un professionnel n’a pas certifié la propreté du site.

7. Nettoyage : pourquoi supprimer le script ne suffit pas

Si quelqu’un a pu écrire dans vos fichiers, considérez le site comme compromis jusqu’à preuve du contraire.

Supprimer la balise script malveillante dans head.tpl est nécessaire mais insuffisant. L’attaquant a obtenu un accès en écriture : il a probablement créé une backdoor (compte admin, webshell, module trojan).

Mon protocole de remise en état :

• Restauration depuis une sauvegarde antérieure à l’infection SI vous êtes certain de la date — sinon, forensic puis nettoyage manuel fichier par fichier.
• Comparaison checksum avec une installation PrestaShop propre de la même version.
• Scan de la base de données (requêtes SQL recherchant base64, eval, script tags).
• Purge de tous les caches (PrestaShop, Smarty, Symfony, Cloudflare).
• Mise à jour PrestaShop core + tous les modules + thème.
• Durcissement serveur (permissions 644/755, PHP disable_functions, WAF Cloudflare ou ModSecurity).
• Monitoring d’intégrité fichiers pendant 30 jours post-incident.

Une boutique « nettoyée » qui se réinfecte en 48h signale une backdoor non détectée.

8. Obligations légales : CNIL, clients, plainte

Si des données de paiement ou des données personnelles de clients ont été exfiltrées, le RGPD impose une notification à la CNIL dans les 72 heures après la prise de connaissance de la violation (article 33). Vous devez documenter : nature de la violation, catégories de données concernées, nombre approximatif de personnes affectées, conséquences probables, mesures prises.

En parallèle :

• Informer les clients affectés si le risque pour leurs droits est élevé (article 34).
• Porter plainte auprès des autorités compétentes si des données bancaires ont été volées.
• Contacter votre prestataire de paiement et votre banque.
• Conserver une trace horodatée de toutes les actions (runbook incident).

Ignorer ces obligations expose à des sanctions CNIL et à des recours clients — en plus de la perte de confiance.

9. Prévention : les 7 réflexes qui bloquent 90 % des attaques

1. Mettre à jour PrestaShop et tous les modules sous 72h après un patch sécurité.
2. Activer la 2FA sur tous les comptes admin.
3. Renommer et protéger le dossier admin (.htpasswd en amont du login).
4. Zéro module nulled — uniquement Addons officiel ou éditeurs reconnus.
5. Désinstaller (supprimer) les modules inutilisés.
6. Sauvegardes 3-2-1 quotidiennes, testées mensuellement.
7. WAF + monitoring d’intégrité fichiers + revue mensuelle des comptes admin.

Ces mesures ne sont pas optionnelles sur une boutique qui traite des paiements. Le skimmer 2026 exploite des failles connues et des négligences courantes — pas des zero-day sophistiqués.

10. PrestaShop 1.7 et 8 : qui est le plus exposé ?

Toutes les versions en production sont concernées si le vecteur d’entrée existe. Cependant, les boutiques PrestaShop 1.7 non maintenues cumulent deux risques : failles de sécurité non patchées depuis fin 2024, et modules de paiement qui ne reçoivent plus de mises à jour compatibles PCI.

Si vous êtes encore en 1.7, cette alerte skimmer doit accélérer votre calendrier de migration vers PrestaShop 8.2 ou 9.1 — pas seulement pour le skimmer, mais pour l’ensemble de votre surface d’attaque. Guide complet : migration PrestaShop 1.7 → 8/9 sans perdre le SEO.

11. Combien coûte une boutique skimmée vs un audit préventif ?

Un audit de sécurité PrestaShop complet coûte entre 1 500 € et 4 000 € selon la complexité. Une boutique skimmée, c’est en moyenne :

• 12 000 € de perte de chiffre d’affaires pendant l’arrêt.
• 3 semaines de remise en état.
• Notification CNIL et communication de crise.
• Remboursements ou litiges clients.
• Déclassement SEO si Google détecte du contenu malveillant.

Un contrat de maintenance à 290 €/mois incluant monitoring et correctifs sous 72h amortit ce risque en moins d’un trimestre. Le calcul est vite fait : la prévention coûte toujours moins cher que l’urgence un dimanche soir.

12. Ma checklist express à imprimer

1. Test navigation privée + mobile sur le tunnel paiement — aujourd’hui.
2. Inspection head.tpl et modules mloader/simplefilemanager — cette semaine.
3. Rotation mots de passe admin, FTP, BDD — cette semaine.
4. Vérification comptes admin + modules installés — cette semaine.
5. Sauvegarde testée + plan incident documenté — ce mois-ci.
6. Mise à jour core + modules + 2FA — ce week-end si pas déjà fait.
7. Audit professionnel si le moindre doute — avant la prochaine commande client.

13. Questions / réponses

Mon back-office est propre, ma boutique peut-elle quand même être infectée ?

Oui. Le skimmer 2026 se désactive quand un administrateur est connecté. Votre back-office et vos tests connectés peuvent sembler normaux pendant que vos clients sont redirigés vers un faux paiement. Seul un test en navigation privée, sans session admin, est fiable.

J’ai supprimé le script dans head.tpl, suis-je safe ?

Non. Supprimer le script visible ne prouve pas que l’attaquant n’a pas laissé une backdoor (compte admin, module trojan, injection en base de données). Considérez le site compromis jusqu’à un audit complet ou une restauration depuis une sauvegarde saine antérieure à l’infection.

Dois-je prévenir la CNIL si je ne suis pas sûr qu’il y ait eu exfiltration ?

Vous devez évaluer le risque dès que vous constatez une compromission. Si des données de paiement ont pu transiter par le skimmer, documentez l’incident et consultez un DPO ou un expert sécurité. En cas de doute sur une fuite de données personnelles, la notification CNIL sous 72h est la règle prudente.

Les modules mloader et simplefilemanager, c’est quoi ?

Ce sont des noms de modules signalés par PrestaShop comme indicateurs de compromission. Si vous les trouvez dans /modules/ sans les avoir installés vous-même, considérez la boutique comme infectée et lancez le protocole d’urgence.

Combien de temps dure un nettoyage complet après skimmer ?

Pour une boutique standard : 2 à 5 jours ouvrés entre forensic, nettoyage, durcissement et validation. Pour une boutique complexe (modules métier, ERP, multi-boutique) : 1 à 3 semaines. La remise en ligne sans validation professionnelle est un pari que la plupart des marchands perdent.

14. Conclusion

Le skimmer PrestaShop 2026 n’est pas une alerte théorique : c’est une menace active qui exploite une faille de perception — les marchands testent depuis le back-office, le malware se cache. Cinq minutes en navigation privée peuvent vous éviter des semaines de crise, une notification CNIL et la perte de confiance de vos clients.

Un doute sur votre boutique ? Audit express de votre tunnel de paiement, inspection head.tpl et rapport sous 48h. Maintenance préventive dès 290 €/mois pour ne plus subir l’urgence.

Demander un audit sécurité →