PrestaShop 8.2.8 et 9.1.5 : patchez votre boutique sans attendre

PrestaShop a publié le 18 août 2026 deux versions de sécurité, 8.2.8 et 9.1.5, qui corrigent cinq vulnérabilités dont trois notées High par l'éditeur. Toute boutique en 8.2.x ou 9.1.x non mise à jour expose ses exports clients, son serveur et ses journaux d'accès.

À retenir

PrestaShop 8.2.8 et 9.1.5, publiées le 18 août 2026, corrigent cinq vulnérabilités dont trois classées High par l'éditeur.
La faille d'injection de formule dans les exports CSV vise la personne qui ouvre le fichier, y compris un comptable ou un client recevant son export RGPD.
Le correctif X-Forwarded-For ne suffit pas seul : le proxy ou le CDN doit réécrire l'en-tête avec l'IP réellement constatée.
La branche 8.2.x est en support étendu et ne reçoit plus que des correctifs de sécurité : la migration vers 9.x doit être planifiée.

Ce que corrige la mise à jour PrestaShop 8.2.8 / 9.1.5

Selon l'annonce officielle du projet PrestaShop, la version 8.2.8 est une release de sécurité pure : elle ne contient aucune nouveauté fonctionnelle, uniquement cinq correctifs de vulnérabilités. Les mêmes correctifs sont intégrés dans PrestaShop 9.1.5, publiée simultanément, qui embarque en plus une centaine de corrections de bugs sur la branche 9.1 avant l'arrivée de PrestaShop 9.2.

Le fait que la 8.2.8 soit une release « security-only » a une conséquence pratique directe : le risque de régression est faible, et l'argument du « on attendra la prochaine grosse version » ne tient pas. Sur une branche 8.2.x désormais en phase de support étendu, l'éditeur précise qu'elle ne reçoit plus que des correctifs de sécurité et des corrections critiques. Autrement dit, chaque patch publié pour cette branche est par définition important.

Les trois failles classées High

Injection de formule dans les exports CSV (8.3/10, CWE-1236, avis GHSA-w6j9-q9rq-wrqg) : les valeurs exportées étaient écrites telles quelles. Une valeur forgée pouvait être interprétée comme une formule par le tableur qui ouvre le fichier. La victime n'est pas le serveur mais la personne qui ouvre l'export : commerçant, salarié, comptable, ou client recevant son export RGPD.
SSRF via les URL d'images à l'import CSV (8.2/10, CWE-918, avis GHSA-xrwj-pq6w-f8m4) : les adresses d'images listées dans un CSV importé étaient téléchargées par le serveur sans vérification. Le serveur allait chercher ce qu'on lui pointait, y compris des ressources internes. L'exploitation demande un compte back-office disposant de la permission d'import.
Usurpation d'IP via l'en-tête X-Forwarded-For (7.3/10, CWE-290, avis GHSA-2cr4-vw9p-pjvf) : PrestaShop lisait la partie de l'en-tête contrôlée par le visiteur au lieu de celle ajoutée par le proxy de la boutique. N'importe quel visiteur pouvait donc se déclarer sous l'IP de son choix, ce qui met à mal la liste d'autorisation du mode maintenance, les journaux d'audit et les protections tierces de type blocage géographique ou limitation de débit.

Deux failles Medium complètent le lot : une injection SQL via les filtres de listes du back-office (6.5/10, CWE-89), exploitable par n'importe quel employé connecté, même avec le profil le plus restreint, permettant de lire des données partout dans la base ; et un défaut de contrôle d'accès sur l'endpoint des notifications du back-office (4.3/10, CWE-862), qui exposait des informations récentes de commandes et de clients à tout employé connecté.

Pourquoi une faille « à privilèges » reste un vrai risque pour une boutique

L'objection classique en réunion : « il faut un compte back-office, donc on est tranquilles ». C'est une lecture incomplète. Sur une boutique e-commerce, les comptes back-office se multiplient vite : le service client, le préparateur de commandes, le comptable externe, l'agence média, le prestataire logistique. Beaucoup de ces comptes utilisent des mots de passe faibles ou réutilisés, et restent actifs longtemps après la fin de la mission. Une injection SQL exploitable par « le profil le plus restreint » signifie concrètement qu'un accès de niveau stagiaire permet de lire la table des clients.

L'injection de formule dans les exports CSV est encore plus sournoise parce qu'elle ne demande aucun privilège d'attaque : la donnée piégée peut arriver par un champ de commande ou de compte client. Le fichier n'est dangereux qu'au moment où quelqu'un l'ouvre, souvent hors du périmètre technique de la boutique, sur le poste d'un comptable. C'est typiquement le genre de vecteur qui échappe aux audits centrés sur le serveur.

Quant à l'usurpation d'IP, elle a un effet en cascade : si vos journaux enregistrent une IP contrôlée par l'attaquant, vos investigations post-incident sont faussées, vos règles de limitation de débit deviennent contournables, et votre mode maintenance filtré par IP n'est plus une barrière. C'est le type de faille qui n'apparaît pas dans les statistiques d'incidents mais qui affaiblit toutes les autres protections.

La configuration du proxy : un point à vérifier même après le patch

Le projet PrestaShop insiste sur un point que nous voyons régulièrement mal traité chez les boutiques hébergées derrière un CDN ou un répartiteur de charge : la gestion correcte des IP est une responsabilité partagée entre l'application et l'hébergement. Le patch corrige le comportement du code, mais si votre proxy frontal se contente de transmettre l'en-tête envoyé par le visiteur au lieu de le réécrire avec l'adresse qu'il constate réellement, le problème persiste côté infrastructure.

Concrètement, la règle est simple : le premier équipement de votre chaîne, celui qui reçoit le trafic public, doit écraser l'en-tête de forwarding, pas l'ajouter à ce que le client a déclaré. L'avis de sécurité GHSA-2cr4-vw9p-pjvf publié par PrestaShop fournit des extraits de configuration prêts à l'emploi pour Nginx et Apache, ainsi que des recommandations pour les utilisateurs de CDN. Dans notre pratique d'hébergement et d'exploitation de sites en production, c'est le point de contrôle le plus souvent oublié lors d'une migration vers un CDN : le site fonctionne, les IP journalisées sont fausses, et personne ne s'en aperçoit avant l'incident.

Comment appliquer la mise à jour PrestaShop sans casser la boutique

Une mise à jour de sécurité sur une boutique en production n'est pas un clic. Le risque réel ne vient presque jamais du core mais des modules tiers et des surcharges de thème accumulées au fil des années. Voici la séquence que nous appliquons sur les boutiques que nous maintenons.

Identifiez votre version exacte dans le back-office (Paramètres avancés, Informations). Si vous êtes en 8.2.x ou 9.1.x, vous êtes concerné. Si vous êtes en 1.7.x, vous n'avez pas reçu ces correctifs et le sujet devient une migration, pas une mise à jour.
Faites une sauvegarde complète de la base de données et des fichiers, et vérifiez que la restauration fonctionne. Une sauvegarde non testée n'est pas une sauvegarde.
Dupliquez la boutique sur un environnement de préproduction identique en version PHP et configuration serveur.
Appliquez le patch via l'Update Assistant (module autoupgrade), recommandé par PrestaShop pour cette mise à jour.
Testez le tunnel d'achat de bout en bout : ajout au panier, transporteurs, moyens de paiement, création de compte, e-mails transactionnels, connexion au back-office, exports.
Vérifiez les modules critiques : paiement, ERP, marketplace, feed produits. Ce sont eux qui cassent, pas le core.
Planifiez la bascule en production sur un créneau à faible trafic, avec la sauvegarde de repli immédiatement disponible.
Contrôlez la configuration du proxy ou du CDN sur la réécriture de l'en-tête X-Forwarded-For, puis vérifiez que les IP journalisées correspondent bien aux visiteurs réels.
Faites le ménage dans les comptes back-office : supprimez les comptes de prestataires inactifs, revoyez les permissions d'import et d'export.

Sur une boutique standard sans surcharge lourde, cette séquence tient dans une demi-journée. Sur une boutique avec ERP connecté, thème sur mesure et quinze modules payants, comptez plusieurs jours de test. C'est précisément l'écart que la maintenance PrestaShop régulière permet de réduire : plus les mises à jour sont espacées, plus chaque intervention devient un projet.

8.2 en support étendu : préparer la suite maintenant

PrestaShop rappelle que la branche 8.2.x est en phase de support étendu et ne reçoit désormais que des correctifs de sécurité et critiques. Traduction budgétaire : rester en 8.2 est tenable à court terme à condition d'appliquer chaque patch sans délai, mais ce n'est pas une position durable. Le jour où la branche sortira du support, une faille équivalente à celles corrigées le 18 août ne sera plus corrigée pour vous.

La branche 9.1, elle, apporte selon l'éditeur un nouveau thème par défaut (Hummingbird 2.0), la gestion multi-transporteurs et un système de remises repensé, sur les fondations modernisées introduites par PrestaShop 9. Le passage de 8.2 à 9.x n'est pas une mise à jour de patch : il implique de vérifier la compatibilité de chaque module et, souvent, de revoir le thème. L'arbitrage raisonnable pour la plupart des PME consiste à patcher immédiatement en 8.2.8, puis à planifier la migration vers 9.x sur un budget et un calendrier identifiés, sans attendre la fin du support. Si vous cherchez un accompagnement sur ce type d'arbitrage, notre équipe e-commerce traite ces sujets au quotidien depuis 2010.

Ce qu'il faut décider cette semaine

Trois décisions suffisent : qui applique le patch et quand, qui teste le tunnel d'achat après mise à jour, et à quelle échéance la migration vers 9.x est budgétée. Si aucune de ces trois questions n'a de réponse aujourd'hui, votre boutique est en maintenance subie, pas pilotée. La différence se mesure le jour d'un incident, quand il faut restaurer une sauvegarde à 22 heures un vendredi.

Un dernier point de méthode : documentez la version installée, la date d'application du patch et la liste des modules testés. Cette trace de quelques lignes fait gagner des heures à la mise à jour suivante et sert de preuve de diligence en cas de contrôle sur la protection des données clients.

Questions fréquentes

Ma boutique est en PrestaShop 1.7, suis-je concerné par ces failles ?

Les correctifs annoncés le 18 août 2026 concernent les branches 8.2 et 9.1, via les versions 8.2.8 et 9.1.5. Une boutique en 1.7.x ne reçoit pas ces correctifs et se trouve sur une base beaucoup plus ancienne. Le sujet n'est alors plus une mise à jour de patch mais une migration, à budgéter comme un projet à part entière.

Combien de temps prend l'application du patch 8.2.8 ?

Sur une boutique standard avec peu de surcharges, la séquence sauvegarde, test en préproduction, mise à jour et recette du tunnel d'achat tient généralement dans une demi-journée. Sur une boutique avec ERP connecté, thème sur mesure et de nombreux modules payants, il faut compter plusieurs jours de tests. Le core PrestaShop casse rarement, les modules tiers beaucoup plus souvent.

Faut-il un compte administrateur pour exploiter ces vulnérabilités ?

Cela dépend de la faille. Le SSRF à l'import CSV exige un compte back-office disposant de la permission d'import. L'injection SQL sur les filtres de listes est exploitable par n'importe quel employé connecté, même avec le profil le plus restreint, et l'usurpation d'en-tête X-Forwarded-For ne demande aucun compte du tout.

Le patch suffit-il à régler le problème d'usurpation d'IP ?

Non, pas systématiquement. PrestaShop précise que la gestion correcte des IP est une responsabilité partagée entre l'application et l'hébergement. Si votre boutique tourne derrière un reverse proxy, un load balancer ou un CDN, il faut vérifier que l'équipement frontal écrase l'en-tête de forwarding avec l'adresse qu'il constate, au lieu de transmettre celle envoyée par le visiteur.

Vaut-il mieux patcher en 8.2.8 ou migrer directement en 9.1.5 ?

Les deux versions embarquent les mêmes correctifs de sécurité. Patcher en 8.2.8 est l'action immédiate, à faible risque de régression puisqu'il s'agit d'une release de sécurité uniquement. La migration vers 9.x implique une vérification de compatibilité de chaque module et souvent une reprise du thème : elle se planifie séparément, mais sans attendre la fin du support de la 8.2.

Sources

Article rédigé le 27/08/2026 par l'équipe Websource à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.