PrestaShop : une faille critique dans le module Recherche à facettes permet la prise de contrôle de votre serveur
Une nouvelle faille de sécurité critique vient d’être confirmée par l’équipe de PrestaShop. Elle concerne cette fois le module officiel Recherche à facettes (ps_facetedsearch), installé sur une très large part des boutiques en ligne pour gérer la navigation par filtres.
Le problème : sous certaines conditions, des requêtes spécialement conçues peuvent être traitées de façon non sécurisée par le module et aboutir à l’exécution de code non autorisé directement sur votre serveur. Et le pire : aucune authentification n’est nécessaire pour exploiter la faille. N’importe quel attaquant peut viser n’importe quelle boutique qui utilise une version vulnérable. Il est impératif de mettre à jour le module sans attendre.
Une faille critique dans le module ps_facetedsearch
La vulnérabilité (référencée GHSA-m5f5-28qr-9g9r) est une injection d'objet PHP située dans le mécanisme de cache du module. Exploitée, elle ouvre la porte à une exécution de code à distance (RCE) : l'attaquant peut faire tourner ses propres commandes sur votre hébergement.
On change de catégorie de risque par rapport à l'injection SQL de 2022 : on ne parle plus seulement de vol de données ou de détournement de paiement, mais d'une prise de contrôle potentielle de la machine elle-même.
Deux facteurs aggravent la situation : le module est extrêmement répandu (il propulse le filtrage produit d’une grande partie des boutiques PrestaShop), et la faille est exploitable sans compte ni connexion. C’est précisément le type de combinaison que les attaquants automatisent en masse.
Versions concernées
- La faille affecte
ps_facetedsearchde la version 3.0.0 jusqu’à la version 4.0.3 incluse. - Toutes les boutiques sous PrestaShop 1.7.1.0 ou supérieur sont potentiellement exposées.
- Le correctif est disponible dans la version 4.0.4 du module.
Si vous ne savez pas quelle version vous utilisez, vous la trouverez dans votre Back-Office, dans la liste de vos modules, en cherchant « Recherche à facettes ».
Comment se protéger : mettez à jour vers la version 4.0.4
Contrairement à la faille de 2022 qui se réglait en retirant quelques lignes de code, il n'existe ici qu'une seule vraie solution complète : passer en version 4.0.4. La marche à suivre :
- Dans votre Back-Office, ouvrez Modules et vérifiez les mises à jour disponibles pour « Recherche à facettes ».
- Mettez le module à jour en v4.0.4.
- Si la mise à jour n'apparaît pas encore, téléchargez la dernière version depuis la page de release officielle et installez-la manuellement.
Après l’opération, vérifiez bien que la version installée affichée dans votre Back-Office est bien la 4.0.4 (ou supérieure).
Et si vous ne pouvez pas mettre à jour immédiatement ? Sur certaines boutiques (module fortement personnalisé, déploiement contraint…), la mise à jour ne se fait pas toujours dans la minute. Le correctif officiel tient en un seul commit que des utilisateurs avancés peuvent appliquer directement à leur copie du module avant redéploiement.
Attention : un patch manuel n’est qu’une rustine, pas la destination. Il ferme cette faille précise mais vous laisse sur une ancienne version, privée des autres correctifs. À considérer comme une solution de transition, en planifiant la montée en 4.0.4 dès que possible. Si vous n’êtes pas à l’aise avec la modification de fichiers en production, faites-le d’abord sur une copie de test (staging) — ou confiez l’opération à un prestataire technique.
Protégez votre boutique PrestaShop avec Unlidot
Notre équipe applique la mise à jour, audite votre boutique, vérifie qu'elle n'a pas déjà été compromise et la nettoie si nécessaire.
Comment savoir si vous êtes impacté(e) ?
Mettre à jour ferme la faille, mais si votre boutique a tourné un certain temps avec une version vulnérable, mieux vaut vérifier qu'elle n'a pas déjà été ciblée. Connectez-vous en FTP ou en SSH et inspectez :
- Des fichiers PHP inattendus dans
modules/ps_facetedsearch/: tout.phpque vous n'avez pas installé est un signal d'alerte. - Des entrées suspectes dans vos logs d'accès, surtout des requêtes répétées ou malformées visant ce dossier.
Vous pouvez aussi consulter Paramètres avancés > Informations de votre Back-Office, qui liste les fichiers du cœur modifiés. Attention : cette vérification seule ne suffit pas à garantir qu’une boutique est saine.
Je pense être infecté(e) ! Que faire ?
Si vous découvrez des fichiers inattendus, une activité suspecte dans vos logs ou tout autre signe de compromission, ne partez pas du principe que la mise à jour du module suffit. Une boutique déjà piratée doit être investiguée et nettoyée correctement.
Commencez par vérifier que vous disposez de sauvegardes récentes de vos fichiers et de votre base (la plupart des hébergeurs sérieux comme Infomaniak ou OVH en réalisent automatiquement). Une fois la boutique confirmée propre, changez vos mots de passe Back-Office et passez en revue les autres modules et identifiants du serveur. Nous recommandons vivement de faire appel à un prestataire technique pour traiter l’incident, valider le nettoyage et mettre la faille en quarantaine — surtout pour une RCE, où la simple présence d’un fichier malveillant peut suffire à recompromettre la boutique.
Renforcer la sécurité de votre serveur
Aucune des mesures ci-dessous ne remplace la mise à jour en 4.0.4. Mais combinées, elles ajoutent des couches de défense et limitent l’impact d’une attaque.
Un pare-feu applicatif (WAF). Il inspecte les requêtes HTTP entrantes et bloque celles qui correspondent à des schémas malveillants connus avant qu'elles n'atteignent PrestaShop. Couche utile, mais de la défense en profondeur : un filtrage par signature peut être contourné en reformulant la requête.
Cloudflare et services « edge ». CDN et reverse-proxy absorbent le trafic et appliquent des règles WAF en périphérie. Même réserve : aucune protection contre une requête qui ne correspond à aucune signature. Bienvenue, jamais une garantie.
Restreindre les fonctions PHP dangereuses. Désactiver les fonctions couramment détournées pour exécuter des commandes système limite ce qu’un code non autorisé peut faire. Dans votre php.ini, via la directive disable_functions :
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec
Les vecteurs typiques sont exec, system, shell_exec, passthru, proc_open, popen et pcntl_exec. PrestaShop n’en dépend pas, mais certains hébergements ou modules tiers peuvent les utiliser : testez d’abord sur un environnement de staging avant la production.
Hygiène générale. Gardez PrestaShop et tous vos modules (natifs comme tiers) à jour, sauvegardez régulièrement et testez vos sauvegardes, et suivez les advisories de sécurité PrestaShop ainsi que des ressources communautaires comme Friends of Presta pour être alerté tôt.
En résumé
Mettez ps_facetedsearch à jour en v4.0.4 dès maintenant si vous utilisez une version 3.0.0 ou supérieure. Vérifiez votre dossier modules/ps_facetedsearch/ et vos logs d’accès pour repérer d’éventuelles traces, et ajoutez un WAF, un filtrage en périphérie et des fonctions PHP restreintes comme couches supplémentaires. Au moindre signe de compromission, traitez-le comme un incident de sécurité — et faites-vous accompagner.
Je sécurise ma boutique avec Unlidot
Mise à jour, audit de compromission, nettoyage et durcissement : on s'occupe de la sécurité de votre boutique PrestaShop de bout en bout.
