Faille PrestaShop blm.php (CVE-2022-31181) : guide 2026

Mis à jour le 31 octobre 2026. Les faits de 2022 ont été revérifiés dans l’avis officiel de PrestaShop et dans les fiches CVE, citées en fin d’article. La partie « Et en 2026 ? » couvre les failles publiées depuis.

En juillet 2022, des boutiques PrestaShop ont été piratées en série. Les attaquants exploitaient une injection SQL pour déposer un fichier blm.php sur le serveur, puis affichaient un faux formulaire de paiement afin de voler les cartes bancaires des clients. La faille principale est référencée CVE-2022-31181 et a été corrigée dans PrestaShop 1.7.8.7.

Cet article explique l’attaque, comment vérifier qu’une boutique n’a pas été touchée, comment la nettoyer, et pourquoi le même schéma reste d’actualité en 2026.

Ce qui s’est passé en juillet 2022

PrestaShop a publié un avis de sécurité le 22 juillet 2022, complété le 25 juillet à la sortie de la version 1.7.8.7. Le correctif porte sur la fonction de cache MySQL de Smarty, le moteur de gabarits de PrestaShop. Cette fonction, rarement utilisée et désactivée par défaut, pouvait être activée à distance par un attaquant, puis servir à faire exécuter du code PHP par le serveur.

La faille est notée 9,8 sur 10 (critique). Elle était exploitée activement au moment de sa publication.

Une erreur fréquente : de nombreux articles de l’époque citent CVE-2022-36408. Ce numéro a été annulé : il avait été attribué par erreur, à la suite d’une faute de frappe. La seule référence valable est CVE-2022-31181.

Le déroulé de l’attaque

L’avis de PrestaShop décrit quatre étapes :

1. Injection SQL : l’attaquant envoie une requête POST vers un point d’entrée vulnérable, le plus souvent un module.
2. Création du fichier : environ une seconde plus tard, une requête GET sans paramètre vers la page d’accueil crée un fichier blm.php à la racine du site.
3. Prise de contrôle : l’attaquant appelle blm.php pour exécuter les commandes de son choix sur le serveur.
4. Vol des cartes : un faux formulaire de paiement est injecté sur la page de commande. Les clients y saisissent leurs coordonnées bancaires, qui partent chez l’attaquant.

PrestaShop précisait que d’autres noms de fichiers ou d’autres méthodes pouvaient être utilisés : l’absence de blm.php ne prouve rien.

Versions et modules concernés

Le point clé : la faille du cœur ne suffisait pas à elle seule. Il fallait aussi une injection SQL, dans un module obsolète, dans un module tiers mal écrit ou dans une ancienne version de PrestaShop.

Le contournement publié à l’époque

En attendant la version 1.7.8.7, PrestaShop recommandait de désactiver le cache MySQL de Smarty en retirant quelques lignes du fichier config/smarty.config.inc.php : les lignes 43 à 46 en 1.7, et 40 à 43 en 1.6. Ces lignes chargent le cache MySQL lorsque ce mode est choisi.

Sur une boutique à jour, ce contournement n’a plus d’utilité. Il reste la seule mesure possible sur une vieille 1.6 qui ne peut pas être mise à jour, en plus d’une migration à prévoir.

Vérifier si votre boutique a été compromise

Dans les journaux d’accès

La trace caractéristique est une suite de trois requêtes rapprochées : un POST vers un module, un GET sur la page d’accueil environ une seconde plus tard, puis un appel à /blm.php.

# Appels au fichier de l'attaque (chemin Apache, à adapter à votre serveur)
grep "blm.php" /var/log/apache2/access.log*

# Requêtes POST vers les modules, à examiner une par une
grep "POST /modules/" /var/log/apache2/access.log* | head -50

Les journaux ne remontent souvent qu’à quelques semaines. Ne pas trouver la trace n’écarte pas une compromission ancienne.

Dans les fichiers

La méthode la plus fiable consiste à comparer les fichiers de la boutique avec une archive propre de la même version de PrestaShop, extraite par exemple dans /tmp/prestashop-clean/.

# Fichiers du cœur qui diffèrent de l'archive officielle
diff -rq /var/www/html/classes/ /tmp/prestashop-clean/classes/
diff -rq /var/www/html/controllers/ /tmp/prestashop-clean/controllers/

# Fichiers PHP présents à la racine (à comparer avec ceux de l'archive)
ls -la /var/www/html/*.php

# Code obfusqué ou évalué dynamiquement (nombreux faux positifs possibles)
grep -rln "eval(\|base64_decode(\|gzinflate(\|str_rot13(" /var/www/html/ --include="*.php" | grep -v "/vendor/"

Les dates de modification ne suffisent pas : un attaquant peut les falsifier, et une mise à jour légitime les change aussi.

Dans la base de données

L’attaque passait par la base. Deux vérifications simples, en adaptant le préfixe ps_ :

-- Le cache Smarty doit être sur "filesystem", pas sur "mysql"
SELECT name, value FROM ps_configuration
WHERE name IN ('PS_SMARTY_CACHING_TYPE', 'PS_SMARTY_CACHE');

-- Comptes administrateur récents ou inconnus
SELECT id_employee, email, lastname, firstname, last_passwd_gen
FROM ps_employee
ORDER BY id_employee DESC
LIMIT 10;

Un cache réglé sur mysql sans raison connue est un signal fort. Une persistance peut aussi se cacher ailleurs en base (configuration, contenus de modules, hooks) et réinfecter la boutique après un nettoyage des fichiers : voir Votre PrestaShop se ré-infecte après chaque nettoyage ? Cherchez en base.

Pour un contrôle des fichiers et de la base en une fois, le module Genisoft Security Scanner analyse la boutique en lecture seule, sans rien modifier. Il est disponible sur PrestaShop Addons.

Sur la page de paiement

Passez une commande de test et vérifiez que le formulaire de paiement est bien celui de votre prestataire (Stripe, PayPal, votre banque). Les skimmers récents se masquent quand un administrateur est connecté : faites le test depuis une navigation privée, sans être connecté au back-office. Voir Skimmer PrestaShop 2026 : il se cache quand vous êtes connecté.

Nettoyer une boutique infectée

1. Mettre le site en maintenance pour stopper les commandes pendant l’intervention.
2. Sauvegarder l’état infecté (fichiers et base) avant toute suppression : cette copie sert à l’analyse.
3. Supprimer blm.php et tout fichier PHP inconnu, puis restaurer les fichiers du cœur depuis une archive propre de la même version.
4. Remettre le cache Smarty sur filesystem s’il a été basculé sur mysql.
5. Changer tous les mots de passe : administrateurs, base de données, FTP ou SFTP, hébergeur, clés d’API des modules de paiement.
6. Mettre à jour PrestaShop et tous les modules, et supprimer les modules inutilisés.
7. Vérifier vos obligations : si des données de paiement ou personnelles ont pu être exposées, le RGPD peut imposer une notification à la CNIL sous 72 heures et, selon le risque, aux clients concernés.

L’ordre des opérations compte : il est détaillé dans Boutique PrestaShop piratée : que faire, dans l’ordre et en urgence. Si vous préférez confier l’intervention, l’agence Genisoft assure le nettoyage des sites piratés et leur sécurisation.

Et en 2026 ? Le même schéma, d’autres failles

La faille de 2022 date, mais sa leçon reste valable : une seule faille dans un module suffit à prendre le contrôle du serveur. Les failles publiées en 2026 le montrent.

Le module de recherche à facettes. La faille CVE-2026-54159, notée 10 sur 10, touche les versions 3.0.0 à 4.0.3 de ps_facetedsearch, un module installé par défaut sur la plupart des boutiques. Les valeurs des filtres de prix et de poids, transmises dans l’adresse, étaient mal contrôlées puis relues depuis un cache, ce qui permettait d’exécuter du code sans aucun compte. La correction est la version 4.0.4 du module. Vérifiez la version dans Modules > Gestionnaire de modules : la mise à jour du cœur ne suffit pas.

Le cœur de PrestaShop. PrestaShop a publié en août 2026 les versions de sécurité 9.1.5 et 8.2.8, qui corrigent cinq failles, dont une injection SQL dans les filtres des listes du back-office. La version stable actuelle est PrestaShop 9.2. Une boutique encore en 1.6 ou 1.7 ne reçoit plus de correctifs : la migration devient elle-même une mesure de sécurité.

Le serveur. Deux failles critiques de PHP ont été corrigées le 21 octobre 2026. Elles concernent toutes les boutiques, quelle que soit leur version de PrestaShop : voir Faille critique PHP : alerte php2shell.

Prévenir

Mises à jour

• Appliquez les versions de sécurité de PrestaShop dès leur publication, après une sauvegarde complète.
• Mettez à jour les modules, y compris les modules natifs, et supprimez ceux que vous n’utilisez plus.
• Suivez les avis de sécurité : le blog officiel de PrestaShop (build.prestashop-project.org) et les avis GitHub du projet.

Bloquer l’exécution de PHP dans les dossiers d’images et d’envoi

Une directive <Directory> n’est pas admise dans un fichier .htaccess. Placez plutôt ce fichier dans chaque dossier concerné, par exemple img/ et upload/. Apache doit autoriser ces directives dans les fichiers .htaccess (AllowOverride).

# .htaccess à placer dans le dossier concerné (Apache 2.4)
<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

Surveillance

• Un pare-feu applicatif (Cloudflare, ModSecurity) filtre une partie des injections, sans remplacer les mises à jour.
• Un contrôle d’intégrité planifié (AIDE, Tripwire ou un script qui compare les fichiers à une référence) signale les fichiers ajoutés ou modifiés.
• Consultez régulièrement les journaux d’accès et d’erreurs.

Points à retenir

1. La faille de 2022 est CVE-2022-31181, corrigée dans PrestaShop 1.7.8.7. Le numéro CVE-2022-36408 est annulé.
2. Elle demandait une injection SQL, presque toujours dans un module : les modules sont la première surface d’attaque d’une boutique.
3. Un nettoyage complet couvre les fichiers et la base, sinon la boutique se réinfecte.
4. En 2026, le schéma se répète : mettre à jour le cœur ne dispense pas de mettre à jour chaque module.

Questions fréquentes

Ma boutique était-elle concernée par la faille de 2022 ?

Elle l’était si elle tournait sur PrestaShop 1.6.0.10 ou plus récent et contenait une injection SQL, par exemple via le module Wishlist en version 2.0.0 à 2.1.0 ou un module tiers vulnérable. Cherchez la trace dans les journaux d’accès et contrôlez fichiers et base : l’absence de blm.php ne suffit pas à conclure.

Le contournement du cache Smarty est-il encore utile en 2026 ?

Non, sur une version de PrestaShop corrigée. Il ne garde un intérêt que sur une ancienne boutique 1.6 qui ne peut pas être mise à jour, en attendant une migration.

Comment savoir si un module de ma boutique a une faille connue ?

Comparez la version de chaque module installé avec les avis de sécurité de son éditeur et avec la base des avis GitHub de PrestaShop. Pour les modules natifs, le gestionnaire de modules signale les mises à jour disponibles.

Faut-il prévenir mes clients en cas d’infection ?

Si des données de paiement ou personnelles ont pu être exposées, le RGPD peut imposer une notification à la CNIL sous 72 heures et, selon le niveau de risque, aux personnes concernées. Faites valider la démarche par la CNIL ou un professionnel du droit.

Un nettoyage des fichiers suffit-il ?

Non. Une persistance peut subsister en base de données ou dans la configuration. Il faut aussi restaurer les fichiers du cœur, changer les mots de passe, contrôler les comptes administrateur et mettre à jour les modules.

Sources

• Avis de sécurité PrestaShop, 22 juillet 2022
• Avis GitHub GHSA-hrgx-p36p-89q4 (CVE-2022-31181)
• Fiche NVD CVE-2022-31101 (module Wishlist)
• Avis GitHub GHSA-m5f5-28qr-9g9r (CVE-2026-54159, ps_facetedsearch)
• PrestaShop 9.1.5 et 8.2.8, août 2026

L'équipe Genisoft Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →