{"id":842427,"date":"2026-10-22T11:49:18","date_gmt":"2026-10-22T11:49:18","guid":{"rendered":"https:\/\/www.knowband.com\/blog\/?p=842411\/"},"modified":"2026-10-22T11:58:28","modified_gmt":"2026-10-22T11:58:28","slug":"vuln%c3%a9rabilit%c3%a9s-critiques-de-php-octobre-2026-ce-que-chaque-propri%c3%a9taire-de-boutique-prestashop-doit-faire-d%c3%a8s-maintenant","status":"publish","type":"post","link":"https:\/\/www.knowband.com\/blog\/fr\/commerce-electronique\/vuln%c3%a9rabilit%c3%a9s-critiques-de-php-octobre-2026-ce-que-chaque-propri%c3%a9taire-de-boutique-prestashop-doit-faire-d%c3%a8s-maintenant\/","title":{"rendered":"Vuln\u00e9rabilit\u00e9s critiques de PHP (octobre 2026) : Ce que chaque propri\u00e9taire de boutique PrestaShop doit faire d\u00e8s maintenant"},"content":{"rendered":"

Veuillez lire ceci en premier. PHP a d\u00e9ploy\u00e9 des correctifs le 21 octobre pour deux failles critiques. Si votre boutique utilise une version de PHP non mise \u00e0 jour, un attaquant pourrait ex\u00e9cuter du code sur le serveur sans aucune authentification. Ces failles ne concernent pas PrestaShop. Vous devez aujourd’hui obtenir trois informations : la version de PHP utilis\u00e9e, la confirmation \u00e9crite de l’application du correctif par votre h\u00e9bergeur et le red\u00e9marrage de PHP depuis.<\/p>\n

La plupart des actualit\u00e9s en mati\u00e8re de s\u00e9curit\u00e9 concernent un plugin ou un th\u00e8me, et la solution se r\u00e9sume \u00e0 un bouton \u00ab Mettre \u00e0 jour \u00bb. Ici, c’est diff\u00e9rent. Votre probl\u00e8me se situe au niveau du moteur de votre boutique, et la solution se trouve sur le serveur, hors de port\u00e9e du back-office. C’est pourquoi il est facile de passer \u00e0 c\u00f4t\u00e9, et c’est pourquoi vous devez prendre un apr\u00e8s-midi pour le r\u00e9soudre calmement et m\u00e9thodiquement.<\/span><\/p>\n

Comment cela s’est d\u00e9roul\u00e9<\/b><\/h2>\n

L’\u00e9quipe PHP avait pr\u00e9venu le 20 octobre de la publication imminente de correctifs de s\u00e9curit\u00e9. D\u00e9couverts le 21 octobre, ces probl\u00e8mes ont re\u00e7u les num\u00e9ros CVE-2026-109618 et CVE-2026-109619. Ces vuln\u00e9rabilit\u00e9s, not\u00e9es 9.2 sur l’\u00e9chelle CVSS v4.0, sont critiques et ont \u00e9t\u00e9 baptis\u00e9es \u00ab php2shell \u00bb. Un avis conjoint a \u00e9t\u00e9 publi\u00e9 par la Commission europ\u00e9enne (DG CNECT), l’ENISA, le CERT-EU, Europol EC3 et le r\u00e9seau CSIRT.<\/span><\/p>\n

La Commission europ\u00e9enne (DG CNECT), l’ENISA, le CERT-EU, Europol EC3 et le r\u00e9seau CSIRTs ont ensuite publi\u00e9 une d\u00e9claration commune demandant aux organisations de d\u00e9m\u00e9nager. <\/span><\/p>\n

Versions corrig\u00e9es : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.<\/span><\/p>\n

Qu’est-ce qui est r\u00e9ellement cass\u00e9 ?<\/b><\/h2>\n

\"\"<\/a><\/p>\n

Ces deux failles peuvent permettre l’ex\u00e9cution de code \u00e0 distance sans authentification. Autrement dit : un inconnu sur Internet pourrait amener votre serveur \u00e0 ex\u00e9cuter ses instructions.<\/span><\/p>\n

La vuln\u00e9rabilit\u00e9 CVE-2026-109618 est un probl\u00e8me de gestion de la m\u00e9moire. Imaginons que PHP soit en train de cr\u00e9er l’espace de travail pour une requ\u00eate entrante et que le serveur manque de m\u00e9moire en cours de route. PHP s’arr\u00eate, mais la routine de nettoyage qui suit consid\u00e8re l’espace de travail incomplet comme termin\u00e9 et l’utilise.<\/span><\/p>\n

La vuln\u00e9rabilit\u00e9 CVE-2026-109619 s’apparente davantage \u00e0 une gueule de bois. Des donn\u00e9es ayant appartenu \u00e0 une requ\u00eate restent pr\u00e9sentes apr\u00e8s la lib\u00e9ration de leur m\u00e9moire, et une requ\u00eate ult\u00e9rieure sur le m\u00eame n\u0153ud de calcul peut les r\u00e9cup\u00e9rer et leur faire confiance.<\/span><\/p>\n

Notez que ces deux \u00e9l\u00e9ments se trouvent dans PHP. PrestaShop n’est pas en cause et ne peut pas s’en prot\u00e9ger, car l’attaque peut se produire avant m\u00eame qu’une seule ligne de code PrestaShop ne soit ex\u00e9cut\u00e9e. Par cons\u00e9quent, une mise \u00e0 jour de module ou du noyau ne change rien. <\/span>La mise \u00e0 jour de PHP corrige le probl\u00e8me.<\/b><\/p>\n

Le probl\u00e8me, c’est \u00e0 qui ?<\/b><\/h2>\n

Toutes les m\u00e9thodes d’ex\u00e9cution de PHP pour le web sont concern\u00e9es : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. Apache avec mod_php repr\u00e9sente le pire sc\u00e9nario, car l’attaque peut se d\u00e9clencher avant m\u00eame l’ex\u00e9cution du code applicatif.<\/span><\/p>\n

Ce que vous devez faire d\u00e9pend de votre environnement d’h\u00e9bergement et de la personne qui g\u00e8re votre installation PHP :<\/p>\n\n\n\n\n\n\n\n\n
Environnement d’h\u00e9bergement<\/th>\nQui g\u00e8re PHP ?<\/th>\nAction recommand\u00e9e<\/th>\n<\/tr>\n<\/thead>\n
Offres mutualis\u00e9s<\/td>\nVotre fournisseur d’h\u00e9bergement<\/td>\nContactez votre h\u00e9bergeur et demandez-lui de confirmer que les correctifs de s\u00e9curit\u00e9 PHP pertinents ont bien \u00e9t\u00e9 appliqu\u00e9s \u00e0 votre environnement.<\/td>\n<\/tr>\n
VPS ou serveur d\u00e9di\u00e9<\/td>\nVous ou votre administrateur syst\u00e8me<\/td>\nInstallez les mises \u00e0 jour de s\u00e9curit\u00e9 appropri\u00e9es pour votre version de PHP ou votre syst\u00e8me d’exploitation, puis red\u00e9marrez les services PHP concern\u00e9s si n\u00e9cessaire.<\/td>\n<\/tr>\n
H\u00e9bergement Docker ou conteneuris\u00e9<\/td>\nL’\u00e9quipe responsable de l’image du conteneur<\/td>\nReconstruisez l’image \u00e0 l’aide d’une image de base PHP avec les correctifs de s\u00e9curit\u00e9 applicables, puis red\u00e9ployez-la et v\u00e9rifiez l’environnement d’ex\u00e9cution.<\/td>\n<\/tr>\n
Versions PHP anciennes ou non prises en charge<\/td>\nVotre fournisseur d’h\u00e9bergement ou administrateur de serveur<\/td>\nV\u00e9rifiez si un correctif de s\u00e9curit\u00e9 du fournisseur est disponible. Dans le cas contraire, pr\u00e9voyez une migration vers une version PHP prise en charge apr\u00e8s avoir v\u00e9rifi\u00e9 la compatibilit\u00e9 avec votre boutique, votre th\u00e8me et vos modules.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Votre liste de choses \u00e0 faire aujourd’hui<\/b><\/h2>\n
    \n
  1. V\u00e9rifiez la version de PHP.<\/b> Back Office, Param\u00e8tres avanc\u00e9s, Informations.<\/span><\/li>\n
  2. \u00c9crivez \u00e0 votre h\u00f4te.<\/b> Posez directement la question : \u00ab Nos serveurs ont-ils \u00e9t\u00e9 corrig\u00e9s pour les vuln\u00e9rabilit\u00e9s CVE-2026-109618 et CVE-2026-109619 ? Tous nos processus PHP ont-ils \u00e9t\u00e9 red\u00e9marr\u00e9s ? \u00bb Conservez la r\u00e9ponse. Remarque : certaines distributions appliquent le correctif silencieusement, sans modifier le num\u00e9ro de version ; par cons\u00e9quent, l\u2019anciennet\u00e9 de ce num\u00e9ro ne permet pas de d\u00e9terminer si le serveur est vuln\u00e9rable.<\/span><\/li>\n
  3. Mettez \u00e0 jour, puis red\u00e9marrez.<\/b> Utilisez une version corrig\u00e9e ou un package patch\u00e9 par le fournisseur. Red\u00e9marrez tous les processus PHP. Le red\u00e9marrage est une \u00e9tape souvent n\u00e9glig\u00e9e. Sur Docker, reconstruisez les images.<\/span><\/li>\n
  4. Sur PHP 8.1 ou une version ant\u00e9rieure ?<\/b> Le projet PHP a publi\u00e9 des correctifs minimaux pour les versions 7.4, 8.0 et 8.1, et de nombreuses distributions Linux et fournisseurs de logiciels \u00e0 support long terme (LTS) proposent des paquets corrig\u00e9s. V\u00e9rifiez si votre distribution en propose. Dans tous les cas, commencez \u00e0 planifier la migration vers une version prise en charge.<\/span><\/li>\n
  5. Pensez ensuite \u00e0 PrestaShop.<\/b> Choisissez une version compatible avec votre version cible de PHP (voir tableau ci-dessous). Cette version sera install\u00e9e apr\u00e8s le correctif, et non avant.<\/span><\/li>\n<\/ol>\n

    Impossible de corriger le probl\u00e8me pour l’instant ? Les recommandations de l’UE proposent une solution : isoler l’application vuln\u00e9rable du r\u00e9seau public jusqu’\u00e0 ce qu’elle soit r\u00e9par\u00e9e. Radicale pour un commerce, certes. Mais il est toujours bon de la garder en r\u00e9serve.<\/span><\/p>\n

    Des solutions temporaires en attendant<\/b><\/h2>\n

    La position officielle de PHP est qu’aucune mesure d’att\u00e9nuation n’est infaillible et que la mise \u00e0 jour est la seule solution s\u00fbre. Consid\u00e9rez les informations de cette section comme un moyen de r\u00e9duire l’exposition aux risques pendant quelques jours seulement.<\/span><\/p>\n