Faille critique dans PHP : ce que les boutiques PrestaShop doivent vérifier

Le 21 octobre 2026, l’équipe de sécurité du projet PHP a publié des correctifs pour deux vulnérabilités critiques du moteur PHP lui-même, notées 9,2 sur 10 en CVSS. PrestaShop a relayé l’alerte le même jour auprès de ses utilisateurs, avec un message clair : aucune de ses versions n’est en cause, et aucune mise à jour de PrestaShop ou d’un module ne corrige le problème. La seule réponse complète consiste à mettre à jour PHP sur le serveur qui héberge la boutique. Le détail technique est public dans l’avis de sécurité officiel du projet PHP, et PrestaShop en a fait une synthèse à destination des marchands dans le billet publié par PrestaShop sur le sujet.

Une faille dans PHP, pas dans PrestaShop

Les deux vulnérabilités, référencées CVE-2026-109618 et CVE-2026-109619, touchent le moteur PHP qui exécute n’importe quelle application écrite dans ce langage, PrestaShop compris mais pas seulement. Elles sont décrites comme exploitables à distance et sans authentification : un visiteur anonyme qui envoie des requêtes construites pour l’occasion peut, selon le scénario, faire planter le processus PHP, provoquer une fuite d’informations ou, dans le pire des cas, exécuter du code sur le serveur. La première vulnérabilité tient à une gestion défaillante de la mémoire lorsqu’une requête est interrompue avant d’être complètement traitée : des données partiellement initialisées peuvent être considérées comme valides lors du nettoyage. La seconde permet à un état interne propre à une requête de survivre après la libération de la mémoire qui le portait, si bien qu’une requête suivante traitée par le même processus peut en hériter. Les installations qui tournent avec mod_php sont présentées comme les plus exposées, mais aucune configuration PHP servant des requêtes web n’est à l’abri.

Qui doit agir, et comment vérifier

La première étape ne demande aucune compétence technique particulière : dans le back-office de la boutique, le menu Paramètres avancés puis Informations affiche la version de PHP utilisée. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Une boutique qui affiche un numéro de version inférieur n’est pas forcément vulnérable : certaines distributions Linux rétro-portent les correctifs de sécurité sans changer le numéro affiché, d’où l’intérêt de poser la question à qui gère le serveur plutôt que de se fier au seul chiffre affiché.

1. Relever la version PHP affichée dans Paramètres avancés > Informations du back-office PrestaShop.
2. Identifier qui gère ce PHP l’hébergeur en infogérance, un serveur administré en interne, ou des images Docker.
3. Demander une confirmation écrite à l’hébergeur si celui-ci gère le serveur, avec la version exacte appliquée.
4. Mettre à jour et redémarrer tous les processus PHP (PHP-FPM, mod_php, tâches en ligne de commande) si le serveur est auto-géré.
5. Reconstruire les images sur la base PHP corrigée et redéployer, en vérifiant qu’aucune ancienne image ne reste active, pour les boutiques en conteneurs.

Ce qui ne suffit pas

Le projet PHP est explicite : il n’existe pas d’atténuation complète hors mise à jour. Un pare-feu applicatif correctement configuré devant le serveur peut réduire l’exposition pendant la fenêtre de correction, à condition que le serveur n’accepte du trafic web que depuis ce pare-feu. Quelques réglages PHP peuvent limiter la casse en attendant : abaisser post_max_size et upload_max_filesize sans casser les imports de catalogue ni l’envoi d’images produit, désactiver session.upload_progress puis redémarrer les processus, et éviter un memory_limit illimité en l’absence d’une limite imposée par ailleurs (conteneur ou groupe de contrôle système). Aucune de ces mesures ne remplace le correctif : un correctif installé mais non rechargé par les processus PHP ne protège pas la boutique.

Un calendrier à anticiper, pas une urgence isolée

PHP 8.1 et les versions antérieures ne reçoivent plus de correctifs officiels : le projet PHP n’a publié que des rétro-portages minimaux pour les lignes 7.4, 8.0 et 8.1, et certaines distributions maintiennent leurs propres paquets corrigés. PHP 8.2 atteindra sa fin de support le 31 décembre 2026, ce qui laisse peu de temps aux boutiques encore sur cette ligne pour planifier la suite. PrestaShop 9 prend en charge PHP 8.1 à 8.5 : une boutique qui tourne encore sur une version antérieure de PrestaShop, où le choix de version PHP est plus contraint, a intérêt à regarder la méthode de migration vers une version maintenue plutôt que de traiter chaque alerte PHP comme un cas isolé. le calendrier de support des versions de PHP permet de vérifier à tout moment quelles lignes PHP sont encore maintenues. Et pour toute boutique amenée à appliquer une mise à jour de sécurité dans la foulée, la méthode suivie pour une mise à jour de sécurité PrestaShop et les vérifications d’hébergement à faire avant toute mise à jour restent la marche à suivre.

Ce qu’il faut retenir

• Deux failles critiques (CVSS 9,2) touchent PHP lui-même, pas PrestaShop ni ses modules.
• Le seul correctif complet est la mise à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, suivie d’un redémarrage des processus PHP.
• La version affichée dans le back-office ne suffit pas à conclure : il faut une confirmation de qui gère le serveur.
• PHP 8.2 sort du support le 31 décembre 2026 : c’est l’occasion de planifier la suite plutôt que de subir la prochaine alerte.