Nos recommandations suite à l’alerte PrestaShop « Vérification recommandée de vos boutiques »
Vous découvrez le terme Skimmer ? Commencez par lire cet article.
Suite à l’envoi par PrestasShop de l’e-mail ci-dessous, nous tenions à préciser un certain nombre de choses.
– Nous n’avons pas connaissance d’une nouvelle faille de sécurité, ou technique de piratage, dans PrestaShop ou un des modules. Il existe de nombreux malware activement utilisés sur PrestaShop, et le malware mentionné dans cet email ne fait pas l’objet d’une campagne particulièrement active. A ce jour, nous ne savons pas pourquoi Shop a choisi de communiquer sur ce malware précisément.
– Le principe d’un skimmer est de rester discret. Par conséquent, les pirates modifient très régulièrement la signature (le code ou l’emplacement) de leurs skimmer, parfois d’un piratage à l’autre. Effectuer, cette recherche est évidemment nécessaire, mais la non présence dudit fichier ne garantit en rien que la boutique n’est pas compromise.
– Pour les boutiques non correctement supervisées, les signaux faibles sont la première source de détection d’un piratage : comportement étrange du Back Office, requête au support client, etc…
Quoi qu’il en soit, ce message ne nous parait pas attirer l’attention sur les véritables enjeux : les CMS Open Source sont des outils très puissant dont la sécurité est la responsabilité de l’exploitant et sont livrés sans aucune protection. C’est donc au marchand et à ses prestataires de mettre en place un ensemble de dispositifs pour protéger la boutique.
Malheureusement, nous constatons aujourd’hui que la grande majorité des boutiques PrestaShop n’ont aucun dispositif de sécurité. Sans dispositif de sécurité, la boutique est exposée à une analyse permanente (crawler) des pirates, est vulnérable à la moindre faille (mise à jour de sécurité non appliquée dans les heures suivant la publication, fuite d’identifiants, trou de sécurité dans le code du développeur, etc… ) et les intrusions ne sont pas détectées.
Les solutions de sécurisation existent …
Les logiciels en saas portant la responsabilité de la sécurisation, ils mettent en oeuvre tous les dispositifs classiques de sécurisation d’une application en accès libre sur internet, en complément de la sécurisation de leur logiciel :
- Détection et blocage du trafic = WAF spécifiquement configuré en fonction du logiciel,
- Gestion des accès = double authentification, enregistrement et contrôle de tous les accès avec droits de modification
- Suivi des modifications = FIM pour détecter toute modification du code
- etc…
Sans ces dispositifs, le piratage d’une application en accès libre sur internet est inéluctable.
… il faut les mettre en place sur votre PrestaShop !
Pour PrestaShop, en Février 2026, il faut au minimum :
- Tenue irréprochable de votre PrestaShop : mise à jour du CMS et de ses modules + configurations Apache-PHP-PrestaSHop
- Double authentification obligatoire sur tous les comptes Back Office
- WAF spécialisé PrestaShop
- Remarque 1 : Cloudflare, même en mode paranoïaque, ne bloque pas la majorité des attaques spécifiques à PrestaShop (car c’est un WAF générique) : il faut créer des règles Custom adaptées au CMS
- Remarque 2 : sans mention spécifique dans l’offre, votre hébergeur / infogéreur ne met pas en oeuvre un WAF spécialisé PrestaShop
Vous êtes un profil technique ? Lisez notre guide de la sécurisation d’une boutique PrestaShop (à venir)
C’est dans ce contexte que Prestafence a été créé : une solution simple pour protéger les boutique PrestaShop. Prestafence intègre notamment un WAF spécialisé PrestaShop, et une solution de double authentification pour le back office, avec enregistrement de tous les accès et de leur localisation géographique.
N’attendez pas le piratage : si ces sécurisations n’ont pas été mises en place, installez Prestafence.
Email de PrestaShop du 12 février 2026
Nous avons récemment identifié une menace de sécurité affectant certaines boutiques en ligne de l’écosystème PrestaShop. Un script malveillant (« digital skimmer ») a été détecté et pourrait avoir entraîné le vol des informations de paiement de certains clients.
Ce malware fonctionne en remplaçant les boutons de paiement légitimes sur la page de commande par des boutons frauduleux. Lorsqu’un client clique sur l’un de ces faux boutons, il est redirigé vers un formulaire de paiement contrefait destiné à capturer ses informations de paiement.
Le skimmer est simplement chargé via une balise <script>, écrite directement dans le fichier _partials/head.tpl du thème actif de la boutique. Cela signifie que l’attaquant a pu modifier un fichier de la boutique.
À l’intérieur de la balise <script>, le code suivant peut être trouvé :
Script supprimé pour raisons de sécurité, voir site PrestaShop
La partie aHR0cHM6Ly9wbHZiLnN1L2J0Lmpz change à chaque fois, mais la structure du code reste la même, et la fonction atob() est toujours utilisée. Du code peut être présent avant ou après (le skimmer tente de se dissimuler en étant légèrement différent sur chaque boutique).
À ce stade, nous vous recommandons vivement d’effectuer une vérification complète de la sécurité de vos boutiques PrestaShop et de vous assurer qu’aucune d’entre elles n’a été compromise. Vous pouvez également consulter cette page pour plus de détails sur la situation.
Nos équipes techniques enquêtent activement sur l’origine de cette attaque et mettent en œuvre toutes les mesures nécessaires pour éviter tout nouvel impact.
Nous vous remercions pour votre vigilance et votre coopération.