Failles PrestaShop : appliquer les correctifs de sécurité publiés, module par module

Une faille annoncée sur PrestaShop se traite en quatre décisions : le produit concerné est-il installé, dans quelle version, existe-t-il un correctif pour votre branche, et comment prouver qu’il est appliqué. Au 14 octobre 2026, le dernier lot d’avis du cœur publiés sur GitHub date du 18 août 2026 : cinq failles, corrigées par les versions 8.2.8 et 9.1.5. La routine de mise à jour est décrite dans la page sur les mises à jour de sécurité et de modules ; celle-ci traite l’urgence d’un avis précis.

• Les avis de sécurité PrestaShop se lisent à trois endroits
• Savoir si une boutique PrestaShop est touchée demande trois relevés
• Le correctif dépend de la branche de PrestaShop installée
• Un correctif ferme la porte sans dire si elle a déjà servi
• Sans correctif publié, trois issues restent : contournement, retrait ou remplacement
• Exiger un registre des avis traités plutôt qu’une promesse de veille
• Un flux vide ne prouve pas qu’un module est sain
• Sources consultées
• Foire aux questions

Les avis de sécurité PrestaShop se lisent à trois endroits

Le cœur et les modules de l’éditeur sont couverts par les avis du dépôt GitHub de PrestaShop, identifiés par un code « GHSA », propre à GitHub. Les modules tiers, par l’association Friends of Presta, qui publie un flux RSS (fil de nouveautés). Le troisième lieu est l’auteur du module, par ses notes de version (déduction).

Friends of Presta publie un avis dans trois cas. Un module ou un thème est fortement exploité. L’auteur ne publie pas de CVE (le numéro public d’une faille) ou ne répond pas. La faille est critique et le pare-feu applicatif (WAF, un filtre qui écarte des requêtes suspectes avant qu’elles atteignent PrestaShop) ne la repère pas.

Savoir si une boutique PrestaShop est touchée demande trois relevés

Le premier relevé est le produit : le module nommé dans l’avis est-il sur le serveur ? Le deuxième est la version, comparée à la plage de l’avis. L’avis de ps_facetedsearch vise les versions 3.0.0 à 4.0.3 incluses.

Le troisième est la condition d’exploitation : le même avis précise que le module doit afficher un modèle de filtres contenant un filtre à curseur de prix ou de poids.

Le numéro de version du module porte parfois celle de PrestaShop : le premier chiffre est celui de PrestaShop. L’avis de ps_checkout appelle « 8.4.4.1 » ou « 8.5.0.5 » les builds corrigées pour PrestaShop 8, « 9.5.0.5 » celle de PrestaShop 9.

Pour le cœur, la version s’affiche dans Paramètres avancés > Informations (Advanced Parameters > Information). Pour les modules, demandez au prestataire un inventaire avec leur version : la page « Installed modules » de la documentation de PrestaShop 8 ne dit pas que la liste du back-office l’affiche.

Le correctif dépend de la branche de PrestaShop installée

L’avis du 4 mai 2026 corrige deux branches, la 8.2.6 et la 9.1.1, et ne propose aucun contournement. Pour une boutique plus ancienne, la question change.

La branche 8.2 est en support étendu depuis la sortie de PrestaShop 9.0.0 (10 juin 2025), d’après l’annonce du 4 juillet 2025 : bugs critiques et sécurité seulement, jusqu’à la sortie de PrestaShop 10. L’annonce de janvier 2023 fixait la fin de la maintenance de la 1.7.8 à la sortie de la 9.0.0 ; celle de juillet 2025 ne liste plus que les branches 8.2, 9.0 et develop. D’après l’annonce du 4 juillet 2019, les correctifs de la 1.6 viennent depuis le 1er juillet 2019 de bénévoles, sur un dépôt dédié.

Sur une 1.7, un avis du cœur publié après le 10 juin 2025 n’a plus de correctif de l’éditeur (déduction). La suite se décide avec la migration de PrestaShop 1.7 vers 8.

Décrire mon besoin →

Un correctif ferme la porte sans dire si elle a déjà servi

Les mesures de l’avis de ps_facetedsearch le montrent : vider le cache du module et chercher des fichiers PHP inattendus dans son dossier. Si vous en trouvez, passez au nettoyage après piratage. Et même à jour, la boutique garde un réglage à vérifier. Derrière un relais (reverse proxy, répartiteur de charge ou CDN, qui sert vos pages depuis des serveurs proches du visiteur), le relais doit écraser l’en-tête X-Forwarded-For, qui porte l’adresse du visiteur, avec celle qu’il voit réellement, précise l’annonce du 18 août 2026.

Sans correctif publié, trois issues restent : contournement, retrait ou remplacement

Pour ps_facetedsearch, l’avis cite trois contournements. Le premier retire les filtres à curseur de prix et de poids des modèles exposés. Le deuxième vide le cache des filtres. Le troisième pose une règle de pare-feu applicatif, un filtre qui écarte des requêtes suspectes avant qu’elles atteignent PrestaShop. L’avis fournit aussi un correctif manuel de code ; la mise à jour vers la 4.0.4 reste la solution qu’il recommande.

Quand l’auteur a disparu, un avis peut imposer le retrait. L’avis du module upsshipping, publié le 21 mai 2026, indique qu’aucune version corrigée n’existe et que l’éditeur est défunt. Il demande de désinstaller le module et de supprimer son dossier : la simple désactivation ne suffit pas, car les fichiers restent accessibles par HTTP. Dans le gestionnaire de modules, l’action « Supprimer » (Delete) retire le dossier.

Exiger un registre des avis traités plutôt qu’une promesse de veille

Faites remettre, pour chaque avis qui touche la boutique, une ligne datée : la référence (GHSA ou CVE), le composant concerné ou non, sa version avant et après, la date de lecture, la date de pose, le test réalisé.

Faites écrire qui lit le flux et à quelle fréquence. Faites écrire le délai d’application après publication, par niveau de gravité. Faites écrire qui paie si le correctif casse un module, et qui fait le retour arrière.

Le prix d’une veille suit le nombre de modules à suivre, l’écart de version à rattraper, la préproduction, les week-ends couverts et l’urgence.

Un flux vide ne prouve pas qu’un module est sain

L’association écrit publier ses avis dans des cas précis : l’absence d’avis sur un module ne dit rien d’une faille non signalée. Un module sans avis, mais sans mise à jour depuis des années, reste à l’inventaire des risques (déduction).

Après un incident de mise à jour, un retour à la sauvegarde d’avant remet aussi la faille en place : le correctif et son contournement sont à rétablir.

Au moment d’écrire par le formulaire de cette page, le message gagne à citer la version de PrestaShop, les noms techniques des modules visés et le dernier avis reçu.

Décrire mon besoin →

Sources consultées

• PrestaShop, dépôt GitHub « PrestaShop/PrestaShop », avis de sécurité GHSA-w9f3-qc75-qgx9 (CVE-2026-44212) et liste des avis, consulté le 14 octobre 2026.
• PrestaShop, dépôt GitHub « PrestaShop/ps_facetedsearch », avis GHSA-m5f5-28qr-9g9r (CVE-2026-54159), consulté le 14 octobre 2026.
• PrestaShop, « PrestaShop 8.2.8 is available », 18 août 2026, consulté le 14 octobre 2026.
• PrestaShop, « Security Policy », prestashop-project.org, consulté le 14 octobre 2026.
• PrestaShop, « PrestaShop 8.2.x is now in the extended support phase », 4 juillet 2025, « PrestaShop 1.7.8 is now in the extended support phase » et « 1.6.1.x : what’s next », consulté le 14 octobre 2026.
• Friends of Presta, « About » et page d’accueil des avis, consulté le 14 octobre 2026.
• Friends of Presta, avis de sécurité des modules ps_checkout (CVE-2025-61922) et upsshipping (CVE-2026-39079), consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de PrestaShop 8, « Installed Modules », consulté le 14 octobre 2026.

Foire aux questions

Un avis sans numéro CVE est-il moins grave ?

Rien ne l’indique. Les cinq avis du cœur publiés avec la 8.2.8 portent un identifiant GHSA, celui de GitHub, et un score de gravité, sans CVE dans l’annonce. La gravité se lit dans le score et la plage de versions de l’avis, pas dans la présence d’un numéro CVE.

Faut-il mettre à jour le cœur quand seul un module est concerné ?

Le correctif de l’avis est la version corrigée du module : la 4.0.4 pour ps_facetedsearch, par exemple. Sa compatibilité avec votre cœur se vérifie auprès de l’auteur avant l’installation ; la mise à jour du cœur est une opération distincte.

En combien de temps l’éditeur corrige-t-il une faille ?

La politique de sécurité de PrestaShop ne chiffre aucun délai : les correctifs de toutes les versions encore maintenues sont préparés « as fast as possible », et la divulgation publique intervient en général une fois le problème identifié et le correctif prêt.

Comment signaler une faille trouvée sur sa boutique ?

La politique de sécurité de PrestaShop indique l’envoi d’un courriel à l’équipe de sécurité ou le programme de bug bounty. Friends of Presta publie aussi une adresse de contact sur sa page « About ». Dans son annonce de 2019 sur la 1.6, l’éditeur demande de ne rien divulguer avant la publication du correctif.