Un client vous écrit : la page de paiement lui a semblé bizarre, ou on lui a demandé sa carte sur un formulaire qu’il ne connaissait pas. Ou bien une alerte de sécurité arrive, et vous ne savez pas si votre boutique est touchée.
Début 2026, PrestaShop a prévenu ses marchands d’une attaque de ce type : un code malveillant remplace les vrais boutons de paiement par de faux, qui envoient les coordonnées bancaires ailleurs. Voici comment nous traitons ce cas.
Comment ce genre d’attaque fonctionne
Le pirate profite d’une faille : une version de PrestaShop pas à jour, un module abandonné, un accès au back-office trop facile à deviner. Il glisse alors quelques lignes dans un fichier ou dans la base de données.
La boutique continue de fonctionner normalement. Seule la page de commande change, et souvent seulement pour certains visiteurs. C’est ce qui rend l’attaque difficile à voir de l’intérieur.
Les signes qui doivent alerter
- Un client signale un formulaire de carte inhabituel, ou une fenêtre de paiement qui ne ressemble pas à celle de votre banque.
- Des commandes restent « en attente de paiement » alors que les clients disent avoir payé.
- Des fichiers modifiés récemment sans que personne n’y ait touché.
- Un compte d’administration que vous ne connaissez pas.
- Votre banque ou votre prestataire de paiement vous signale une anomalie.
Ce que nous faisons tout de suite
D’abord, couper l’accès au faux paiement, quitte à mettre la commande en pause quelques heures. Protéger vos clients passe avant tout le reste.
Ensuite, chercher le code ajouté, dans les fichiers comme dans la base. Nous comparons la boutique avec une version saine de PrestaShop et de vos modules : ce qui diffère saute aux yeux.
Puis nous changeons tous les accès : back-office, serveur, base de données, clés des modules de paiement.
Un exemple précis : retrouver les fichiers modifiés
Une commande simple liste les fichiers du thème et des modules modifiés ces sept derniers jours :
$ find themes modules -type f -mtime -7 \( -name "*.tpl" -o -name "*.js" \)
themes/montheme/templates/checkout/_partials/steps/payment.tpl
modules/monpaiement/views/js/front.jsSi personne n’a touché à la boutique cette semaine, ces deux fichiers sont les premiers suspects. Nous les comparons ligne par ligne à leur version d’origine.
Fermer la porte d’entrée
Nettoyer sans comprendre par où le pirate est entré, c’est le revoir revenir. Nous cherchons la faille dans les journaux du serveur et dans les modules installés, puis nous la corrigeons.
Souvent, la vraie réponse est une mise à jour de PrestaShop et des modules, ou le remplacement d’un module qui n’est plus suivi. Si votre boutique est encore en 1.6 ou 1.7, voyez la page migrer PrestaShop vers la version 9.
Prévenir plutôt que nettoyer
Une boutique à jour, des modules suivis, des accès personnels avec des mots de passe solides et un œil régulier sur les fichiers modifiés : cela suffit à écarter la grande majorité de ces attaques.
C’est ce que comprend notre maintenance. Pour en savoir plus, voyez notre page hébergement et maintenance, ou notre page agence PrestaShop.