PrestaShop piraté : détecter et nettoyer un skimmer bancaire

Le pire piratage est celui qui ne casse rien

Quand une boutique PrestaShop piratée tombe en erreur 500, le marchand s'en aperçoit dans l'heure. Quand elle est équipée d'un skimmer, elle continue de fonctionner parfaitement : les commandes passent, les clients paient, et un script injecté dans la page de paiement recopie discrètement les numéros de carte vers un serveur tiers.

La vague observée sur PrestaShop début 2026 suit ce schéma. Le point d'entrée n'est presque jamais le cœur : c'est un module tiers non mis à jour, parfois installé des années plus tôt et oublié.

Deux conséquences immédiates pour un marchand français : la perte de conformité PCI DSS auprès de son prestataire de paiement, et l'obligation de notifier la CNIL sous 72 heures au titre de l'article 33 du RGPD.

Les signaux qui doivent alerter

Aucun de ces signaux n'est une preuve à lui seul, mais chacun mérite une vérification :

• des clients signalent des débits frauduleux peu après une commande chez vous ;
• votre prestataire de paiement vous contacte à propos d'un taux de fraude anormal ;
• un fichier JavaScript du thème a une date de modification récente alors que vous n'avez rien publié ;
• une balise <script> pointant vers un domaine inconnu apparaît dans le code source de la page de commande ;
• Google Search Console signale un contenu trompeur ou des pages de spam indexées.

Les domaines d'exfiltration imitent volontairement des services légitimes : noms contenant cdn, analytics, jquery, tag-manager, sur des extensions peu courantes. Un domaine qui ressemble à Google sans être google.com est le signal le plus fiable.

Le diagnostic en SSH, en cinq commandes

Fichiers modifiés dans les sept derniers jours :

find . -type f -name "*.php" -mtime -7 -not -path "./var/cache/*"
find . -type f -name "*.js" -mtime -7 -not -path "./var/cache/*"

Code obfusqué dans les thèmes et les modules :

grep -rl "eval(atob\|eval(String.fromCharCode\|_0x" themes/ modules/

Portes dérobées classiques :

grep -rl "eval(\$_POST\|assert(\$_REQUEST\|base64_decode(\$_" . --include="*.php"

Côté base de données, une injection historique bien documentée consiste à glisser du JavaScript dans le nom de la boutique, réaffiché sur toutes les pages :

SELECT name, value FROM ps_configuration WHERE value LIKE '%<script%';
SELECT id_employee, email, active FROM ps_employee;

Un compte employé que vous ne reconnaissez pas, ou une valeur de configuration contenant du HTML, valent confirmation.

La procédure de nettoyage

Nettoyer un site piraté dans le désordre garantit une réinfection. L'ordre compte.

1. Figer la scène. Faites une copie complète des fichiers et de la base avant de toucher à quoi que ce soit. C'est votre seule pièce à conviction et votre seul moyen de comprendre le vecteur d'entrée.

2. Couper l'hémorragie. Passez la boutique en maintenance. Tant que la page de paiement est en ligne, les numéros continuent de partir.

3. Restaurer le code depuis une source saine. Retéléchargez le cœur PrestaShop à la version exacte installée et écrasez les fichiers, en préservant img/, upload/, download/, vos modules maison et config/settings.inc.php. Réinstallez chaque module tiers depuis son éditeur, jamais depuis une archive trouvée sur le serveur.

4. Nettoyer la base. Corrigez les valeurs de ps_configuration altérées, supprimez les comptes employés inconnus, et inspectez les blocs CMS ainsi que les descriptions produits qui contiennent du <script>.

5. Tout renouveler. Mots de passe employés, mot de passe de la base, accès FTP/SSH, clés API des modules de paiement, et les clés cryptographiques de config/settings.inc.php (_COOKIE_KEY_, _RIJNDAEL_KEY_). Régénérer ces clés déconnecte toutes les sessions, y compris celle de l'attaquant.

6. Fermer la porte d'entrée. Sans cette étape, la réinfection intervient en quelques jours. Mettez à jour tous les modules, vérifiez les advisories publiés par Friends-of-Presta pour chacun d'entre eux, et appliquez les correctifs de sécurité du cœur.

Durcir la boutique pour la suite

• Renommer le dossier d'administration et le protéger par une authentification HTTP supplémentaire.
• Interdire l'exécution de PHP dans img/, upload/ et download/ via la configuration du serveur.
• Activer la double authentification pour tous les comptes employés.
• Mettre en place un pare-feu applicatif et une surveillance de l'intégrité des fichiers : un fichier PHP créé dans modules/ doit déclencher une alerte.
• Sauvegarder quotidiennement, avec une rétention d'au moins 30 jours. Une sauvegarde de 7 jours ne sert à rien face à une intrusion découverte au bout de trois semaines.

Si votre boutique a été compromise via un module de recherche à facettes non corrigé, lisez également notre analyse de la faille ps_facetedsearch.

Intervention d'urgence

Un skimmer coûte plus cher chaque jour qu'il reste en place. Nous auditons, nettoyons et sécurisons, avec un rapport écrit du vecteur d'entrée. Diagnostic gratuit, réponse sous 1h — nous contacter.