Faille ps_facetedsearch : la mise à jour PrestaShop à ne pas rater

Une note de 10 sur 10, exploitable sans aucun compte

Le 3 juin 2026, l'équipe PrestaShop a publié un correctif d'urgence pour ps_facetedsearch, le module de recherche à facettes installé par défaut sur la quasi-totalité des boutiques depuis la version 1.7.1.0. La faille ps_facetedsearch corrigée porte le score maximal de l'échelle CVSS : 10.0.

Trois caractéristiques la rendent redoutable :

• elle ne demande aucune authentification : ni compte client, ni accès back-office ;
• elle s'exploite depuis le front-office, avec une simple requête HTTP ;
• elle aboutit à une exécution de code à distance, c'est-à-dire au dépôt d'un fichier PHP pilotable sur votre serveur.

Autrement dit, un robot qui scanne des boutiques PrestaShop peut prendre la main sur la vôtre sans que rien n'apparaisse dans votre historique d'administration.

Comment la faille fonctionne

Le module met en cache les blocs de filtres pour éviter de recalculer les facettes à chaque visite. Les valeurs des filtres à curseur (prix, poids) sont lues dans l'URL, puis stockées sous forme sérialisée dans ce cache.

Le problème vient de la relecture. Jusqu'à la version 4.0.3, le module appliquait la fonction PHP native unserialize() à ces valeurs sans validation suffisante en amont. Un attaquant peut donc forger une URL contenant un objet PHP malveillant. À la désérialisation, cet objet déclenche une chaîne de gadgets présente dans les dépendances de PrestaShop et finit par écrire un fichier arbitraire dans le dossier du module.

Le correctif officiel remplace unserialize() par \Tools::unSerialize(), la surcouche sécurisée de PrestaShop.

Êtes-vous concerné ?

Versions vulnérables : 3.0.0 à 4.0.3. Version corrigée : 4.0.4.

Vérifiez votre version dans Modules > Gestionnaire de modules, en cherchant « Recherche à facettes ». Vous pouvez aussi lire la balise <version> du fichier modules/ps_facetedsearch/config.xml.

En base de données, une requête suffit :

SELECT name, version FROM ps_module WHERE name = 'ps_facetedsearch';

En dessous de 4.0.4, considérez la boutique comme exposée, y compris si les filtres ne sont affichés que sur quelques catégories : le contrôleur reste joignable.

Le correctif : deux chemins possibles

Mettre à jour le cœur. PrestaShop a publié le même jour les versions 8.2.7 et 9.1.4, qui embarquent le module corrigé. C'est la voie recommandée si vous êtes déjà proche de ces versions.

Mettre à jour le seul module. Téléchargez ps_facetedsearch 4.0.4 depuis le dépôt officiel et remplacez le dossier. C'est l'option la plus rapide quand une montée de version du cœur suppose un vrai chantier de recette.

Dans les deux cas, videz var/cache/prod/ après l'opération et purgez le cache du module. Si vous ne pouvez pas intervenir tout de suite, appliquez les contournements publiés avec l'advisory : retirer les filtres à curseur des templates publics, vider le cache de la recherche à facettes, et bloquer au niveau du pare-feu applicatif les requêtes dont la query string contient des motifs de sérialisation PHP (O:, ;i:).

Vérifier si la boutique a déjà été visitée

Un correctif ne referme pas une porte déjà utilisée. Après la mise à jour, cherchez les traces d'un dépôt de fichier.

Fichiers PHP récemment modifiés dans les modules :

find modules/ -name "*.php" -mtime -60 -ls

Motifs typiques de porte dérobée :

grep -rl "eval(\$_POST\|eval(base64_decode\|assert(\$_REQUEST" modules/ themes/ override/

Vérifiez également :

• le dossier modules/ps_facetedsearch/ : tout fichier .php étranger à la distribution officielle est suspect ;
• les logs d'accès de l'hébergeur, à la recherche de requêtes contenant des chaînes anormalement longues ;
• la table ps_employee : un compte administrateur inconnu signe une compromission installée dans la durée ;
• les fichiers .htaccess et robots.txt, souvent modifiés pour dissimuler des pages de spam.

Si vous trouvez quelque chose, ne vous contentez pas de supprimer le fichier. Une intrusion s'accompagne presque toujours d'une seconde porte dérobée. Il faut changer tous les mots de passe employés, régénérer les clés de config/settings.inc.php dont _COOKIE_KEY_, et restaurer depuis une sauvegarde antérieure à l'intrusion. Notre article sur une boutique PrestaShop piratée détaille la procédure complète.

L'enseignement : un module par défaut n'est pas un module sûr

Beaucoup de marchands surveillent leurs modules tiers et laissent les modules natifs vivre leur vie. Cet épisode rappelle que le code livré par défaut est présent sur des centaines de milliers de boutiques : c'est précisément celui qui intéresse le plus les attaquants.

Trois habitudes réduisent le risque de façon spectaculaire :

• suivre les publications de sécurité de PrestaShop et de Friends-of-Presta ;
• appliquer les correctifs de sécurité sous 72 heures, en passant par une préproduction quand la boutique est complexe ;
• tenir un inventaire des versions de modules, pour répondre en cinq minutes à la question « suis-je concerné ? ».

C'est exactement ce que couvre un contrat de maintenance PrestaShop.

Besoin d'un audit tout de suite ?

Nous vérifions votre version, appliquons le correctif et recherchons les traces d'intrusion. Diagnostic gratuit, réponse sous 1h, de 9h à 22h 7j/7.