Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques qui permettent de prendre la main sur un serveur sans aucun identifiant. Toute boutique PrestaShop est concernée, de la version 1.6 à la 9, parce que la faille n’est pas dans PrestaShop mais dans PHP, le langage qui le fait tourner. La seule protection complète est une version de PHP corrigée : 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Si votre boutique tourne sur une version plus ancienne, la question n’est plus seulement la mise à jour, c’est votre version de PrestaShop.
Ce qui s’est passé
Le 20 octobre, le projet PHP a prévenu qu’une mise à jour de sécurité critique sortirait le lendemain. Le 21 octobre à 16 h, heure de Paris, il a publié l’avis et les correctifs.
- Deux failles, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 chacune. Certains hébergeurs les ont surnommées « PHP2Shell ».
- Elles permettent d’exécuter du code à distance, sans authentification.
- Elles touchent toutes les façons de servir PHP sur le web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est le plus élevé avec mod_php, pour lequel le projet a démontré une attaque qui se déclenche avant même que PrestaShop ne s’exécute.
- Le projet ne signale pas d’attaque constatée à ce jour. Les hébergeurs ont pourtant réagi tout de suite : alwaysdata, par exemple, a bloqué des requêtes et coupé l’envoi de fichiers sur ses sites PHP dès le matin du 21, avant de déployer les correctifs dans la journée.
Le 23 octobre, une troisième faille, moins grave, a été annoncée (CVE-2026-115560). Le réglage de contournement recommandé est le même que pour la deuxième.
Pourquoi PrestaShop est en première ligne
Aucun module de sécurité, aucun réglage du back-office ne protège une boutique contre ces failles : l’attaque passe sous PrestaShop. Ce qui compte, c’est la version de PHP. Et sur PrestaShop, la version de PHP dépend de celle de la boutique.
| Version de PrestaShop | PHP le plus récent supporté | Ce PHP reçoit-il encore des correctifs ? |
|---|---|---|
| 1.6.1 | 7.1 | non, depuis décembre 2019 |
| 1.7.8 | 7.4 | non, depuis novembre 2022 |
| 8.0 à 8.2 | 8.1 | non, depuis le 31 décembre 2025 |
| 9.0 | 8.4 | oui, jusqu’au 31 décembre 2028 |
| 9.1 et 9.2 | 8.5 | oui, jusqu’au 31 décembre 2029 |
Une boutique en 9.x peut donc passer sur une version corrigée sans changer une ligne de code. Une boutique en 1.6, en 1.7 ou en 8.x tourne sur un PHP que le projet ne maintient plus. Pour ces versions, le projet PHP a exceptionnellement publié des correctifs minimaux pour PHP 7.4, 8.0 et 8.1, et certains hébergeurs corrigent eux-mêmes leurs anciennes versions. Votre boutique n’est protégée que si votre hébergeur l’a fait.
Ce que nous avons vérifié sur notre serveur
Nos propres sites tournent sur un serveur Plesk chez IONOS, une configuration courante pour une boutique PrestaShop : Apache, PHP-FPM et plusieurs versions de PHP installées côte à côte. Le 23 octobre, nous l’avons contrôlé en trois points, ceux qu’il faut vérifier sur une boutique.
- Le PHP qui sert les pages. Plesk fait tourner chaque site dans son propre groupe de processus PHP-FPM. Celui d’ydca.fr est rattaché à PHP 8.4, en version 8.4.27 : la version corrigée. Aucun module mod_php n’est chargé dans Apache.
- Les processus en service. Remplacer les fichiers de PHP ne suffit pas : un processus démarré avant la mise à jour garde l’ancien code en mémoire jusqu’à son redémarrage. Sur notre serveur, les fichiers ont été remplacés le 21 octobre, et les processus PHP en service ont démarré après.
- Les autres usages de PHP. ydca.fr n’a aucune tâche planifiée sur le serveur, et la ligne de commande, qui sert à nos opérations de maintenance, utilise aussi la version 8.4.27.
Trois enseignements de ce contrôle :
- Lire le numéro complet, pas la branche. « PHP 8.4 » ne dit rien ; 8.4.26 est vulnérable, 8.4.27 ne l’est plus.
- Vérifier la date de démarrage des processus, pas seulement la version installée.
- Faire l’inventaire de toutes les versions présentes. Une boutique PrestaShop lance souvent des tâches planifiées (exports de catalogue, flux vers les places de marché) ; celles qui passent par la ligne de commande n’utilisent pas forcément le même PHP que les pages.
Ce qu’il faut faire cette semaine
- Relever la version exacte de PHP de la boutique. Dans le back-office : Paramètres avancés, puis Informations.
- Demander par écrit à votre hébergeur s’il a installé une version corrigée, ou s’il a corrigé lui-même votre ancienne version, et s’il a redémarré les processus PHP ensuite. Une réponse datée vaut mieux qu’un « oui, tout est à jour ».
- Si votre boutique est en 9.x et que la réponse est non, faire passer PHP à la version corrigée de la même branche (par exemple de 8.4.26 à 8.4.27). C’est une mise à jour de maintenance, sans changement de comportement attendu.
- Si votre hébergeur ne peut pas corriger tout de suite, lui demander d’appliquer les mesures d’attente décrites dans l’avis de php.net. Elles se règlent côté serveur, pas dans PrestaShop, et le projet PHP précise qu’elles ne remplacent pas la mise à jour.
- Surveiller les journaux du serveur et les comptes administrateurs de la boutique dans les jours qui suivent.
Ce qu’il ne faut pas faire
Changer de branche de PHP en production sans test. Passer une boutique 1.7 de PHP 7.4 à 8.4 pour « être à jour » la casse à coup sûr : le cœur, le thème et la plupart des modules ne sont pas prévus pour.
Migrer dans la précipitation. Une montée de version de PrestaShop se prépare sur une copie de la boutique, avec ses modules, son thème et ses développements spécifiques, paiements en mode test et e-mails coupés. Faite en urgence, elle crée plus de risques qu’elle n’en retire.
Le vrai sujet : la dette de version
Cette faille sera corrigée et oubliée. Le problème qu’elle révèle, lui, reste : une boutique en 1.6, en 1.7 ou en 8.x dépend d’un PHP que plus personne ne maintient officiellement. Cette fois, le projet PHP a publié un correctif pour les anciennes versions. Rien ne dit qu’il le fera la prochaine fois.
Le calendrier se resserre aussi pour les versions récentes : PHP 8.2 ne recevra plus de correctifs après le 31 décembre 2026. Une boutique en 9.0 sur PHP 8.2 a dix semaines pour passer à une version plus récente.
La sortie durable, c’est PrestaShop 9, qui accepte PHP jusqu’à 8.5 et donc des correctifs jusqu’en 2029. Nous accompagnons ces montées de version, de la 1.6 et de la 1.7 jusqu’à la 9 : notre page Agence PrestaShop décrit la méthode. Avant de chiffrer, un audit PrestaShop fait l’inventaire de ce qui doit migrer : version, modules, thème, surcharges et hébergement.
En résumé
La faille est dans PHP, pas dans PrestaShop, et elle se corrige par une version de PHP à jour. Les boutiques en 9.x se protègent en une mise à jour de maintenance. Les autres dépendent de leur hébergeur aujourd’hui, et d’une migration à préparer pour demain.
Vous ne savez pas quelle version de PHP fait tourner votre boutique, ou si elle est corrigée ? Demandez un audit.
Sources consultées le 23 octobre 2026 : avis de sécurité du projet PHP des 20, 21 et 23 octobre 2026 et calendrier des versions maintenues (php.net) ; suivi d’incident n° 494 d’alwaysdata ; prérequis système de PrestaShop 1.7, 8 et 9 et annonce de PrestaShop 9.2.0.
