Ce classement croise la fréquence de chaque faille et sa gravité. Il s’appuie sur les 230 avis de sécurité publiés par Friends of Presta, une association de développeurs PrestaShop, que nous avons comptés le 12 octobre 2026, sur les alertes du blog officiel de PrestaShop et sur les rapports de sociétés de sécurité (Sansec, Sucuri). Pour chaque faille, nous indiquons comment la repérer et comment la corriger, sans détailler la façon de l’exploiter.
Sur PrestaShop, la sécurité du serveur et les mises à jour reviennent au marchand ou à son prestataire, à la différence de Shopify (voir notre comparatif PrestaShop ou Shopify).
Ce que disent les 230 avis de sécurité
- 212 avis portent sur des modules, 13 sur le cœur de PrestaShop, le reste sur des dépendances ou des travaux de recherche.
- 163 sont classés critiques, 52 élevés.
- 201 sont exploitables sans aucun compte sur la boutique.
- 144 sont des injections SQL.
- 47 mentionnent une exploitation active, souvent pour installer un voleur de cartes bancaires sur la page de paiement.
Ces chiffres comptent les failles publiées. Le nombre d’avis par an (141 en 2023, 2 en 2026) suit l’activité des chercheurs bénévoles qui les publient. Aucune statistique publique ne donne le nombre d’attaques, ni la part des piratages qui passe par un module. PrestaShop a désigné les modules et le code ajouté aux boutiques comme porte d’entrée dans ses alertes de 2022 et de 2025, sans donner de chiffre.
1. Injection SQL dans un module tiers
C’est la faille la plus publiée : 144 avis sur 230, dont 42 signalés comme exploités. Un paramètre envoyé par le visiteur arrive dans une requête à la base de données sans être filtré. L’attaquant peut alors lire la base (clients, mots de passe hachés des administrateurs), se créer un compte administrateur ou écrire du code sur le serveur.
Repérage : Lister les modules installés et leur version, puis chercher chacun par son nom technique (le nom de son dossier dans /modules/) dans la liste des avis de Friends of Presta. Une partie des modules visés arrive avec les thèmes vendus sur les marketplaces : le marchand ne les a pas choisis un par un.
Correction : Mettre le module à jour vers la version corrigée. Si l’éditeur ne publie plus de correctif, supprimer le dossier du module : un module désactivé ou désinstallé reste exploitable tant que ses fichiers sont sur le serveur.
2. Faux formulaire de paiement injecté dans le thème
Le 12 février 2026, PrestaShop a écrit à tous les marchands pour leur demander de vérifier le fichier _partials/head.tpl de leur thème actif (relayé par 202 ecommerce). Un script ajouté dans l’en-tête de page remplace les boutons de paiement par un faux formulaire de carte bancaire. Dans une variante décrite par Sansec en février 2026, le client saisit sa carte dans le faux formulaire, puis il est renvoyé vers le vrai et la saisit une seconde fois. Le paiement aboutit et personne ne se plaint.
Le script ne s’active pas quand une session administrateur est ouverte. Le marchand qui teste sa propre page de paiement depuis son navigateur habituel ne voit donc rien.
Repérage : Ouvrir la page de paiement depuis un navigateur où l’on n’est pas connecté au back-office. Chercher dans le code de la page un script qui contient atob( suivi d’une longue suite de caractères, et des champs de carte bancaire affichés directement dans la page au lieu du cadre fourni par le prestataire de paiement.
Correction : Restaurer le thème depuis une copie saine, puis vider les dossiers de cache (themes/<thème>/assets/cache/ et var/cache/) : sur une boutique décrite par un éditeur de modules en mai 2026, les fichiers compilés en cache ont continué à servir le faux formulaire après le nettoyage du thème. Fermer ensuite la porte d’entrée, en général une faille de module (point 1).
3. Script caché dans la configuration de la boutique
PrestaShop a documenté deux campagnes. En juillet 2022, les attaquants activaient le stockage du cache des gabarits en base de données pour écrire un fichier sur le serveur. En janvier 2025, le nom de la boutique, enregistré en base, contenait un script qui capturait les saisies des clients.
Repérage : Regarder le code de la page là où s’affiche le nom de la boutique (titre, texte alternatif du logo, pied de page) : une balise <script> ou une suite de caractères encodés n’a rien à y faire.
Correction : Nettoyer la valeur en base, désactiver le cache des gabarits en base de données s’il est actif, et corriger le module qui a servi de point d’entrée.
4. Fichiers du cœur modifiés et portes dérobées
Tous les incidents détaillés que nous avons lus comportent un fichier PHP ajouté ou modifié. Sucuri décrit en août 2024 un voleur de cartes caché à la fin du fichier config/autoload.php : les recherches dans la base et dans les fichiers n’avaient rien trouvé, et il a fallu relire les fichiers du cœur un par un. Sur une boutique décrite en mai 2026, la porte dérobée était en place depuis plus de 60 jours avant sa découverte.
Repérage : Comparer les fichiers de la boutique à ceux de la version officielle de PrestaShop et des modules installés. Chercher des fichiers .php dans les dossiers qui ne devraient contenir que des images ou des fichiers déposés (/upload, /img, /var/cache).
Correction : Remplacer le cœur et le thème par une copie saine, changer tous les mots de passe et clés (base de données, comptes administrateurs, prestataires de paiement), puis chercher ce qui pourrait réinstaller la porte dérobée : tâches planifiées, comptes ajoutés sur le serveur.
5. Téléchargement de fichiers et fuite de données clients par un module
Friends of Presta compte 7 avis sur des envois de fichiers mal contrôlés, 21 sur des accès à des fichiers hors de leur dossier, et 17 où un visiteur peut télécharger des données personnelles. Ces dernières touchent notamment des modules d’export de commandes et d’étiquettes de transport. Une fuite de données clients engage la responsabilité du marchand au titre du RGPD, même sans prise de contrôle de la boutique.
Le module upsshipping en donne un exemple : faille publiée en mai 2026 (CVE-2026-39079), journaux contenant des données clients accessibles publiquement, éditeur disparu. Aucun correctif ne sortira.
Correction : Mettre à jour ou supprimer le module, et interdire l’exécution de PHP dans les dossiers où les visiteurs peuvent déposer des fichiers.
6. Le module de filtres livré avec PrestaShop
Le 3 juin 2026, PrestaShop a publié une faille du module ps_facetedsearch, la recherche à filtres installée par défaut (avis de sécurité). Elle est notée 10 sur 10, exploitable sans compte, en une seule requête, sur les versions 3.0.0 à 4.0.3. Au 12 octobre 2026, aucune exploitation n’avait été rapportée.
Correction : Mettre le module à jour en version 4.0.4. À défaut, retirer les curseurs de prix et de poids des filtres et vider le cache des filtres.
7. Dossier d’installation oublié et mode débogage actif
En avril 2026, Sansec a relevé plus de 200 boutiques dans 27 pays, surtout en France, en Italie, en Pologne et en République tchèque, dont le dossier /install était encore en place. L’assistant d’installation permet de réécrire la configuration et de se créer un compte administrateur. La même étude a trouvé 15 boutiques dont l’outil de débogage de Symfony était accessible, avec les identifiants de la base.
Correction : Supprimer le dossier /install (ou /install-dev) plutôt que le renommer : les robots cherchent aussi les variantes comme install.old. Passer _PS_MODE_DEV_ à false dans config/defines.inc.php.
8. Adresse du back-office devinable
Friends of Presta a publié en 2023 une liste de 799 adresses de back-office relevées sur des boutiques compromises, et signale que les robots testent les dossiers du type admin suivi de chiffres. Avec une injection SQL (point 1), l’attaquant se crée un compte administrateur. Connaître l’adresse du back-office lui permet ensuite de s’y connecter.
Correction : Donner au dossier du back-office un nom impossible à deviner, en restreindre l’accès aux adresses IP de l’équipe quand c’est possible, et activer la double authentification. Créer un compte par personne, sans compte partagé.
9. Une version de PHP qui ne reçoit plus de correctifs
PrestaShop 8 fonctionne avec PHP 8.1 au plus, et PHP 8.1 ne reçoit plus de correctifs de sécurité depuis le 31 décembre 2025 (php.net). Une boutique en PrestaShop 8 tourne donc sur un PHP sans correctifs. PrestaShop 9 demande PHP 8.1 au minimum, et la version 9.2 accepte jusqu’à PHP 8.5.
Le 21 octobre 2026, PHP a corrigé une faille critique, notée 9,2 sur 10 et exploitable sans compte (CVE-2026-109618). Les versions corrigées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12 (avis de sécurité). L’avis ne mentionne pas PHP 8.1, qui ne recevra pas de correctif.
Repérage : L’en-tête X-Powered-By des réponses du serveur, quand il est affiché, donne la version de PHP. L’hébergeur l’indique aussi dans son interface.
Correction : Passer PHP à la dernière version de sa branche (8.2.35, 8.3.36, 8.4.27 ou 8.5.12 au moins). Une boutique en PrestaShop 8 doit d’abord passer en version 9 pour quitter PHP 8.1. La situation de chaque version est détaillée dans notre article sur les versions de PrestaShop encore maintenues.
10. Filtres explorés par les robots
Cette faille ne donne pas accès à la boutique : elle la rend lente ou indisponible. Chaque combinaison de filtres produit une adresse différente (paramètre ?q= dans l’URL), que les robots d’exploration, dont ceux des outils d’IA, parcourent une par une. La table qui stocke le cache des filtres grossit sans fin, et la base de données comme le serveur saturent. Sur une boutique que nous avons examinée en 2026, cette table atteignait 91 Go. C’est la même table de cache que celle visée par la faille du point 6.
Correction : Freiner les requêtes ?q= qui ne viennent pas du filtrage normal de la page, par exemple avec une règle de protection chez l’hébergeur ou chez Cloudflare. Un blocage complet du paramètre casse le filtrage lui-même. Les pages filtrées doivent porter une balise canonical vers la catégorie et une consigne de non-indexation.
Par où commencer
Les vérifications les plus rapides, dans l’ordre :
- supprimer le dossier
/installs’il existe et désactiver le mode débogage - vérifier que
ps_facetedsearchest en version 4.0.4 ou plus - lister les modules installés et les chercher dans la liste de Friends of Presta, puis supprimer les dossiers des modules inutilisés
- renommer le dossier du back-office et activer la double authentification
- ouvrir la page de paiement sans être connecté au back-office et vérifier qu’aucun script inconnu n’y tourne
- vérifier que PHP est au moins en 8.2.35, 8.3.36, 8.4.27 ou 8.5.12
Un contrôle qui ne trouve rien ne prouve pas que la boutique est saine. Un faux formulaire de paiement peut ne s’activer qu’après l’ajout au panier, une seule fois par visiteur, et jamais pour un administrateur connecté.