Faille PHP du 21 octobre 2026 : votre boutique PrestaShop est-elle exposée ?

Oui, toutes les boutiques PrestaShop sont concernées, puisque la faille est dans PHP lui-même et pas dans PrestaShop. Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques, surnommées PHP2Shell, qui permettent d'exécuter du code à distance sans être authentifié. Les versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Or, d'après la documentation officielle de PrestaShop, seules les versions 9 de PrestaShop tournent sur ces branches de PHP. Une boutique en 1.6, en 1.7 ou en 8 ne peut pas recevoir de version de PHP officiellement corrigée.

Que permet la faille PHP2Shell ?

Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619, et le projet PHP leur donne à chacune une note de 9,2 sur 10 (CVSS v4.0). La première vient de la gestion d'un manque de mémoire, qui peut interrompre PHP pendant qu'il prépare une requête ; la seconde, d'un état interne qui survit à la mémoire qui le portait. Dans les deux cas, l'avis de sécurité de PHP parle d'exécution de code à distance par un attaquant non authentifié.

Concrètement, quelqu'un qui n'a aucun compte sur votre boutique peut lui faire exécuter ses propres instructions. Sur une boutique, cela veut dire l'accès aux fichiers, à la base de données, donc aux comptes clients et aux commandes, et la possibilité de modifier les pages, celle du paiement comprise.

Le projet PHP précise que toutes les installations de PHP qui servent des pages web sont exposées, quel que soit le mode de fonctionnement : PHP-FPM, Apache avec mod_php, où le risque est le plus élevé, php-cgi, FrankenPHP ou LiteSpeed. Mettre à jour PrestaShop ou ses modules n'y change rien : c'est l'interpréteur qui est en cause.

La faille est-elle déjà exploitée ?

Les sources ne disent pas toutes la même chose, et il faut le dire tel quel. Les détails ont fuité avant la date prévue, ce qui a poussé le projet PHP à annoncer le correctif dès le 20 octobre pour le publier le lendemain. La société de sécurité watchTowr dit avoir observé des tentatives d'exploitation depuis le 21 octobre sur ses pièges à attaquants. D'après le même relevé, l'agence américaine CISA n'avait pas encore ajouté ces failles à son catalogue des failles exploitées le 22 octobre, et le Centre canadien pour la cybersécurité signale une preuve de concept publique, sans exploitation active constatée de son côté.

Les agences publiques ne prennent pas de risque. Le Centre national de cybersécurité britannique (NCSC) demande de mettre à jour, et, si ni la mise à jour ni les réglages temporaires ne peuvent être appliqués rapidement, d'envisager de couper le site le temps de le corriger. Le Centre canadien pour la cybersécurité a publié une alerte le 21 octobre, qui recommande d'appliquer les mises à jour sans attendre.

Quelles versions de PrestaShop peuvent recevoir un PHP corrigé ?

Chaque version de PrestaShop n'accepte qu'une plage de versions de PHP. En croisant les tableaux de compatibilité de PrestaShop avec l'avis de PHP et le relevé de watchTowr, on obtient ceci :

Pour PHP 7.3 et les versions plus anciennes, PHP 5 compris, watchTowr confirme qu'elles sont touchées et qu'aucun correctif n'existe. Pour PHP 7.4, 8.0 et 8.1, le projet PHP ne publie plus de version, mais il a déposé des correctifs minimaux dans son code source. Les appliquer demande de recompiler PHP, ce que fait un hébergeur ou une distribution Linux qui maintient ces vieilles branches, pas un marchand.

Le cas des boutiques en PrestaShop 8 est celui qui surprend le plus. La 8 paraît récente, mais elle plafonne à PHP 8.1, que le projet PHP ne maintient plus. Elle se retrouve dans la même situation que la 1.7.8 : protégée seulement si l'hébergeur a appliqué un correctif de son côté.

Que faire cette semaine ?

Vérifiez votre version de PHP. Dans le back-office de PrestaShop, la page Paramètres avancés > Informations affiche la version de PHP du serveur. Notez-la avec votre version de PrestaShop, et situez-vous dans le tableau.

Écrivez à votre hébergeur. Demandez-lui si votre version de PHP a reçu le correctif des failles CVE-2026-109618 et CVE-2026-109619, et à quelle date. En hébergement mutualisé, c'est lui qui tient PHP, et sa réponse décide de tout le reste. Une réponse vague n'est pas un oui.

Si vous êtes en PrestaShop 9, passez à PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 selon votre version, puis redémarrez PHP. Le projet PHP est net : la mise à jour est le seul choix sûr.

Si la mise à jour ne peut pas se faire tout de suite, l'avis de PHP liste des réglages temporaires, à faire appliquer par l'hébergeur ou la personne qui gère le serveur : memory_limit, post_max_size, et surtout session.upload_progress.enabled=0, qui couvre aussi une troisième faille annoncée le 23 octobre, CVE-2026-115560. PHP le dit lui-même : ces réglages ne rendent pas une installation sûre, ils réduisent le risque en attendant.

Surveillez la boutique. La même page Informations liste les fichiers modifiés par rapport à l'installation d'origine : jetez-y un œil. Un fichier PHP inconnu dans les dossiers du site, un compte administrateur que vous n'avez pas créé, une page de paiement modifiée : ce sont les signes d'une intrusion. Au moindre doute, le conseil du NCSC s'applique, et une boutique fermée quelques heures coûte moins cher qu'une base clients dans la nature.

Faut-il refondre sa boutique après PHP2Shell ?

Si votre boutique n'est pas en 9, oui, il faut la planifier. PHP2Shell montre noir sur blanc ce que veut dire tourner sur une version de PHP que plus personne ne maintient : le jour où la faille sort, il n'y a pas de correctif à installer. Une 1.6 tourne sur un PHP abandonné depuis décembre 2019, une 1.7.8 sur un PHP abandonné depuis novembre 2022, une 8 sur un PHP 8.1 qui n'a plus de nouvelle version. Ce sera vrai à la prochaine faille aussi.

Et l'horloge tourne pour tout le monde : PHP 8.2 cessera de recevoir des correctifs le 31 décembre 2026. Une boutique en PrestaShop 9 qui tourne sur PHP 8.2 aura donc, elle aussi, une mise à jour de PHP à prévoir d'ici deux mois.

Le chemin dépend de votre point de départ. Depuis une 1.6, le module officiel de mise à jour impose deux étapes, de la 1.6 à la 1.7, puis de la 1.7 à la 9 ; les modules et le thème sont à vérifier à chaque marche, et les URL à protéger pour ne pas perdre votre référencement. Depuis une 8, le saut est plus court. Dans tous les cas, cela se prépare en semaines, pas en jours, d'où l'intérêt de commencer l'inventaire maintenant, pendant que l'hébergeur tient la boutique à flot. Le détail, version par version, est dans notre article sur la 1.6 : maintenir ou refondre.

Vous ne savez pas où se situe votre boutique, ou ce que coûterait le passage en 9 ? Écrivez-nous avec l'adresse de la boutique, sa version de PrestaShop et celle de PHP : on vous répond avec un plan de passage et son périmètre.

FAQ

PrestaShop a-t-il publié un correctif pour PHP2Shell ? Non, et ce n'est pas à lui de le faire : la faille est dans PHP, pas dans PrestaShop. Mettre à jour PrestaShop ou ses modules ne la corrige pas. Seule la mise à jour de PHP, ou un correctif appliqué par l'hébergeur, protège la boutique.

Ma boutique PrestaShop 1.6 est-elle vulnérable à PHP2Shell ? Oui. La 1.6.1 n'accepte pas de PHP plus récent que la 7.1, et aucune version de PHP 7.3 ou antérieure n'a de correctif, d'après watchTowr. La protection dépend entièrement de votre hébergeur, et la seule sortie durable est la migration.

PrestaShop 8 est-il à l'abri ? Pas d'office. Les versions 8.0 à 8.2 de PrestaShop s'arrêtent à PHP 8.1, que le projet PHP ne maintient plus ; il n'existe qu'un correctif minimal dans le code source, à appliquer par l'hébergeur. Il faut PrestaShop 9 pour tourner sur une version de PHP officiellement corrigée.

Comment savoir si mon hébergeur a corrigé PHP ? Demandez-lui par écrit si votre version de PHP inclut les correctifs des failles CVE-2026-109618 et CVE-2026-109619. La version affichée dans Paramètres avancés > Informations doit être au moins 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 ; en dessous, seul l'hébergeur peut confirmer qu'un correctif a été rétroporté.

Faut-il fermer sa boutique ? Pas forcément. Le NCSC britannique conseille d'envisager la mise hors ligne seulement si la mise à jour et les réglages temporaires ne peuvent pas être appliqués rapidement. Si votre hébergeur confirme le correctif, la boutique peut rester ouverte.