Ma boutique PrestaShop a été piratée sans qu’aucun mot de passe ne fuite

La question « qui a eu mon mot de passe » ne se pose pas toujours

Quand une boutique est compromise, le premier réflexe est de chercher un identifiant volé : un ancien prestataire encore dans les accès, un poste de travail infecté, un mot de passe réutilisé ailleurs. C’est une piste légitime et elle est parfois la bonne. Mais une partie des failles publiées ces dernières années sur l’écosystème PrestaShop ne demandent rien de tout cela. Elles s’exploitent depuis l’extérieur, sur une page publique de la boutique, sans compte, sans session, sans la moindre action de votre part.

C’est ce qu’on appelle une exploitation non authentifiée. Le serveur reçoit une requête qui ressemble à une visite ordinaire, sauf qu’une des valeurs transmises est fabriquée pour déclencher un comportement que l’auteur du module n’avait pas prévu. Le module traite cette valeur comme une donnée de travail normale ; selon la faille, cela finit en requête de base de données détournée, ou en code exécuté sur le serveur. À aucun moment un mot de passe n’intervient. Changer tous les identifiants après coup ne referme donc pas la porte : elle n’a jamais été tenue fermée par un identifiant.

Second malentendu courant : « mon back-office est protégé, j’ai restreint les accès ». Protéger le back-office reste une bonne pratique, mais ces failles ne passent pas par le back-office. Elles passent par la boutique elle-même, celle que vous voulez précisément laisser ouverte à tous vos visiteurs. Ce n’est pas non plus un phénomène récent : le 22 janvier 2025, PrestaShop alertait déjà officiellement sur une vague d’attaques exploitant des injections SQL présentes dans des modules tiers, et non dans le cœur.

Deux surfaces publiques : une page de filtres, une fenêtre promotionnelle

Le 3 juin 2026, PrestaShop a publié l’avis de sécurité GHSA-m5f5-28qr-9g9r, référencé CVE-2026-54159, sur le module officiel de navigation à facettes ps_facetedsearch : celui qui affiche les filtres de prix, de marque ou de caractéristiques sur vos pages de catégorie. Le score CVSS est de 10,0, le maximum de l’échelle. Les versions 3.0.0 à 4.0.3 sont concernées, la version corrigée est la 4.0.4.

La cause est une désérialisation non sûre des données de filtre mises en cache : les valeurs des curseurs de prix et de poids, qui transitent par l’URL, étaient sérialisées puis relues avec unserialize(). Le résultat est une injection d’objet PHP, et de là une exécution de code à distance. L’avis indique que l’exploitation est possible à distance, sans compte et sans authentification, en une seule requête, et qu’elle peut mener à une compromission complète du serveur. La faille a été trouvée par Frédéric Moreau (Antadis) et Gilles Caudal (Datalinx).

Le lendemain, le 4 juin 2026, PrestaShop a publié les versions 9.1.4 et 8.2.7. Elles ne modifient pas le cœur et ne changent aucun comportement : elles embarquent uniquement ps_facetedsearch 4.0.4, pour qu’une installation neuve parte avec le module corrigé (la 9.1.4 met aussi à jour des dépendances, Symfony 6.4.41 et Twig 3.27.1). Autrement dit, sur une boutique déjà installée, c’est la version du module qui compte, pas celle du cœur. Beaucoup de marchands vérifient la seconde et concluent trop vite.

Le second exemple vient d’un module tiers de fenêtres promotionnelles, advancedpopupcreator, édité par Idnovate. L’avis du 16 février 2026, CVE-2025-69633, score CVSS 9,8, décrit une injection SQL exploitable sans authentification sur toutes les versions antérieures à la 1.2.7 ; le correctif est la 1.2.7, et l’avis recommande de supprimer le module s’il n’est pas utilisé. Le détail qui compte pour vous est ailleurs : les tentatives apparaissent dans les journaux du site comme de simples requêtes POST /. Rien ne les distingue d’un trafic ordinaire sans outil dédié. C’est exactement pour cette raison que beaucoup de marchands ne trouvent aucune trace d’intrusion et se rabattent sur l’hypothèse du mot de passe volé.