Faille PHP : quelle gravité avec PHP2Shell et que faire

Depuis le 20 octobre 2026, l’alerte PHP2Shell impose une vérification immédiate sur les sites PrestaShop, WordPress et WooCommerce. Le sujet ne concerne ni un module précis ni un thème : il touche le cœur de PHP, donc la couche qui exécute votre boutique au quotidien.

Le point qui change la priorité est simple : les deux failles sont classées critiques, avec risque d’exécution de code à distance sans authentification et fuite mémoire pouvant exposer des secrets applicatifs. Si votre site tourne sur une branche PHP exposée, attendre le prochain créneau de maintenance vous laisse inutilement en risque.

Dans cet article, vous allez voir qui est concerné, comment vérifier la vraie version PHP utilisée par votre site, quoi faire selon votre hébergement, et quoi prévoir si votre boutique est encore bloquée sur une ancienne branche.

PHP2Shell : ce qui a été publié et pourquoi l’alerte est immédiate

Au 23 octobre 2026, les informations utiles sont suffisantes pour agir. Les correctifs sont publiés et, au 22 octobre 2026, le CERT-FR signalait déjà des preuves de concept connues. Pour un responsable e-commerce, le bon réflexe est donc simple : vérifier l’exposition, corriger, puis contrôler l’état de la boutique.

La chronologie à retenir depuis le 20 octobre 2026

Le 20 octobre 2026, PHP a annoncé une publication de sécurité imminente pour deux vulnérabilités critiques. Les détails ont fuité avant l’embargo. Les correctifs officiels ont ensuite été publiés le 21 octobre 2026 à 16 h, heure de Paris, avec les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12.

Le point utile pour vous : si votre site n’utilise pas au moins une de ces versions corrigées, ou un paquet fournisseur explicitement backporté, il faut le considérer comme exposé. PHP rappelle aussi que la mise à jour reste la seule option sûre : avis de sécurité PHP et versions corrigées.

Les deux failles en une phrase claire

PHP2Shell désigne ici deux failles du cœur de PHP : CVE-2026-109618, liée à une corruption lors d’un dépassement mémoire en fin de requête, et CVE-2026-109619, liée à un état global d’une requête réutilisé par la suivante sur le même processus, avec use-after-free et fuite mémoire.

Les deux sont notées 9,2 en CVSS v4.0. Dit autrement : ce n’est pas une alerte théorique. Au 22 octobre 2026, le CERT-FR signalait déjà des preuves de concept connues.

La gravité est bien critique pour une boutique en ligne

Pour une boutique, la question n’est pas seulement de savoir si le serveur peut planter. La vraie question est de savoir ce qu’un attaquant peut atteindre avant que vous le voyiez. Sur ce point, le niveau de risque est élevé.

Exécution de code à distance sans authentification : ce que cela change

PHP indique que les deux failles peuvent permettre une exécution de code à distance sans authentification. Cela veut dire qu’un attaquant n’a pas besoin d’un compte client, d’un accès au back-office ou d’un module déjà compromis pour tenter quelque chose. Si le moteur PHP en face est vulnérable, la surface d’exposition existe au niveau du traitement des requêtes HTTP.

Cloudflare a indiqué voir du trafic d’attaque dès la divulgation publique, ce qui confirme que le sujet est passé très vite du stade d’alerte au stade des tentatives réelles à surveiller : analyse Cloudflare sur les protections déployées contre PHP2Shell. Cela ne prouve pas des campagnes ciblées sur PrestaShop, WordPress ou WooCommerce en particulier, et il faut rester précis sur ce point.

Fuite mémoire : pourquoi mots de passe, jetons et clés API sont concernés

L’avis GHSA-6wmf-4rv5-p3rp décrit un état global de requête qui peut survivre dans un worker puis être réutilisé par la requête suivante sur le même processus. Le résultat possible : use-after-free, fuite mémoire, puis potentiellement RCE. L’autre avis, GHSA-w8hw-w9fx-j79w, porte sur une corruption liée à un dépassement mémoire en fin de requête.

Pour un commerçant, la conséquence concrète est simple : des secrets applicatifs présents en mémoire peuvent être exposés. Cela peut concerner des mots de passe, des jetons et des clés API. Une boutique peut donc sembler encore debout tout en gardant un risque sérieux sur le paiement, les connecteurs, l’espace client ou l’administration. Le mécanisme de CVE-2026-109619 est décrit dans l’avis officiel : advisory GitHub sur la RCE via stale global state.

Qui est concerné selon votre version PHP et votre hébergement

La bonne méthode consiste à vous situer d’abord sur deux axes : votre branche PHP, puis votre mode d’exécution. C’est ce duo qui détermine l’urgence et le type d’action.

Les branches PHP à considérer comme exposées

Les branches officiellement corrigées sont 8.2, 8.3, 8.4 et 8.5 à partir des versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Toutes les versions antérieures de ces branches sont affectées.

Les branches 5.x, 7.x, 8.0 et 8.1 doivent aussi être considérées à risque. Pour 8.1 et avant, il n’y a plus de support upstream. Des rétroportages peuvent exister selon les fournisseurs pour 7.4, 8.0 et 8.1, mais ils restent limités. Rien n’est annoncé sous 7.4. L’erreur fréquente consiste à croire qu’une branche encore disponible dans un panneau d’hébergement est forcément saine. Ce n’est pas un critère suffisant.

Pourquoi Apache mod_php et PHP-FPM doivent être traités en priorité

Qualys recommande de traiter Apache mod_php comme le cas le plus urgent. PHP-FPM est également concerné, ainsi que php-cgi, FrankenPHP et LiteSpeed. Si vous ne savez pas comment votre site exécute PHP, partez du principe qu’il faut vérifier sans attendre, puis confirmer côté hébergeur ou infogérance.

Le point pratique : une boutique qui répond n’est pas une boutique protégée. Le risque vise le moteur PHP lui-même. Qualys détaille ce point et rappelle aussi qu’un paquet système ou hébergeur peut intégrer un correctif sans afficher exactement le numéro upstream attendu : évaluation du risque PHP2Shell par Qualys.

Le cas particulier de l’hébergement mutualisé

En mutualisé, l’hébergeur peut avoir patché ses clusters rapidement, mais cela ne dispense pas de contrôler la branche PHP choisie dans votre panneau client. Vous pouvez donc avoir un hébergeur réactif, tout en gardant un site exposé si vous restez sur une branche ancienne comme 8.1 ou avant.

Comment vérifier la vraie version de PHP utilisée par votre site

C’est l’étape la plus simple, et pourtant c’est là que beaucoup se trompent. Le piège classique consiste à regarder une version en ligne de commande ou dans un contrat d’hébergement, puis à croire que le site web tourne forcément dessus.

PrestaShop : où vérifier dans le back-office

Sur PrestaShop, vérifiez d’abord dans Paramètres avancés > Informations. Vous voyez ainsi la version PHP réellement remontée par la boutique. Faites cette vérification avant de changer quoi que ce soit, puis refaites-la après intervention.

Si votre site montre une version antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 sur une branche encore supportée, l’action est claire : mise à jour immédiate. Si vous êtes en 8.1, 8.0 ou 7.x, il faut en plus vérifier si votre fournisseur annonce un backport. Sans cette confirmation, considérez la boutique comme à risque.

WordPress et WooCommerce : le chemin le plus sûr

Sur WordPress et WooCommerce, passez par Outils > Santé du site. C’est le chemin le plus simple pour voir la version PHP utilisée par le site web. Là aussi, ne vous fiez pas d’abord à ce que le serveur devrait utiliser : vérifiez ce que WordPress voit réellement.

Sur des environnements avec plusieurs sites ou plusieurs pools, deux applications du même serveur peuvent ne pas utiliser la même configuration PHP. C’est une erreur fréquente sur VPS et dédiés après des changements partiels.

Pourquoi la version CLI peut tromper

La commande php -v en SSH peut différer de la version réellement utilisée par le site web. Vous pouvez donc lire une version rassurante en ligne de commande alors que le front, lui, tourne encore sur une autre pile.

Autre cas fréquent : un paquet fourni par l’OS ou l’hébergeur embarque le correctif sans afficher le dernier numéro de version upstream. Quand vous êtes sur VPS, dédié ou offre administrée, la bonne pratique est de croiser trois choses : la version vue par le site, la version des paquets, et l’avis du fournisseur.

Quoi faire maintenant, dans le bon ordre

Le bon ordre évite deux erreurs : patcher à moitié, ou redémarrer trop tard. Voici la séquence utile pour un site en production.

Mettre à jour PHP ou sélectionner la bonne branche dans le panneau d’hébergement

Premier réflexe : appliquez la version corrigée si elle est disponible. En mutualisé, cela peut vouloir dire sélectionner la bonne branche dans le panneau d’hébergement. En VPS ou dédié, cela veut dire mettre à jour les paquets fournis par votre distribution ou votre prestataire.

Si vous êtes marchand PrestaShop et que la boutique est déjà sensible côté disponibilité, prévoyez en parallèle une intervention d’urgence sur PrestaShop si le changement de branche casse le front, le back-office ou le tunnel. Et si vous voulez réduire le risque de coupure sur les prochains incidents techniques, gardez sous la main les contrôles qui évitent qu’une panne coupe votre boutique.

Redémarrer PHP-FPM ou Apache après la mise à jour

Sur un VPS ou un serveur dédié, la mise à jour ne suffit pas si les processus concernés ne redémarrent pas. Il faut redémarrer PHP-FPM ou Apache selon le mode d’exécution réellement utilisé par le site. Le redémarrage fait partie des actions à prévoir aussi après une mitigation provisoire.

Erreur fréquente : mettre à jour un paquet, vérifier rapidement le site, puis oublier que des workers en mémoire utilisent encore l’ancien état. Sur une faille qui implique précisément des processus et de la mémoire, ce détail compte.

Pourquoi un WAF ou une mitigation temporaire ne suffit pas

PHP indique qu’il n’existe pas de mitigation complète et que la mise à jour est la seule option sûre. Les contournements provisoires ont une utilité, mais ils ne corrigent pas PHP. Ceux cités officiellement sont session.upload_progress.enabled=0 pour réduire le périmètre de CVE-2026-109619, le blocage des requêtes multipart inutiles, fatal_error_backtraces=0 sur 8.5, puis le redémarrage des processus PHP. L’avis GHSA ajoute aussi que pm.max_requests=1 peut réduire le risque si la performance n’est pas prioritaire.

Un WAF peut aider à gagner du temps. Cloudflare a poussé des protections par défaut pour ses clients WAF. Mais un filtrage n’enlève pas la vulnérabilité du moteur PHP. Si la branche reste exposée, vous gardez un risque résiduel.

Si votre boutique est bloquée en PHP 7.x ou 8.1, lancez un chantier cadré dès maintenant

C’est le cas le plus inconfortable. En urgence, vous voulez réduire le risque. En pratique, une vieille boutique ne monte pas toujours de version PHP sans casse. Il faut donc traiter le sujet comme un vrai chantier, pas comme un simple clic dans un panneau d’hébergement.

Pourquoi la montée de version casse parfois une boutique ancienne

Quand une boutique reste sur 7.x ou 8.1, le blocage vient souvent d’un ensemble connu : modules incompatibles, thème ancien, overrides fragiles, connecteurs plus maintenus. Tant que ce point n’est pas traité, vous restez dépendant d’une branche qui n’offre plus les mêmes garanties de support.

Sur PrestaShop, c’est souvent le moment de revoir les composants les plus risqués et de repérer un module PrestaShop mal codé avant de le garder en production. Le gain n’est pas seulement la compatibilité : c’est aussi la baisse du risque sur les prochaines mises à jour.

Quels contrôles faire si vous suspectez déjà une compromission

Après patch, l’absence d’erreur visible ne prouve pas l’absence de compromission. Si votre branche PHP était exposée, il faut faire contrôler les journaux HTTP et PHP, confirmer le mode d’exécution réellement utilisé, puis évaluer l’exposition possible des mots de passe, jetons et clés API présents sur le serveur.

Le critère de décision est simple : si vous ne pouvez pas écarter l’exposition de secrets applicatifs, prévoyez leur rotation dans le périmètre concerné. Attendre un symptôme évident n’est pas une bonne méthode sur un sujet de fuite mémoire.

Quand passer d’un correctif immédiat à un chantier de compatibilité cadré

Si la mise à jour de PHP casse le site, le tunnel ou l’administration, repassez en mode projet dès que l’urgence est contenue. Il faut alors lister les incompatibilités, décider de ce qui se corrige vite et de ce qui doit être remplacé, puis tester la montée de version dans un environnement séparé avant retour en production.

Si votre boutique PrestaShop est bloquée sur une vieille branche PHP, je peux intervenir en support PrestaShop ponctuel ou au mois pour cadrer la montée de version, puis sécuriser la maintenance mensuelle d’une boutique PrestaShop. Diagnostic gratuit, réponse sous 24 h, devis sous 24 h ouvrées.

Questions fréquentes

Mon site PrestaShop, WordPress ou WooCommerce est-il concerné si je ne touche jamais directement au code PHP ?

Oui, potentiellement. PHP2Shell touche le cœur de PHP, pas seulement du code personnalisé. Si votre site exécute une branche PHP exposée, le risque existe même sans développement maison récent. Le bon réflexe est donc de vérifier la version PHP réellement utilisée par le site, puis de confirmer si elle est corrigée ou si votre fournisseur a publié un backport documenté.

Comment vérifier la vraie version de PHP utilisée par mon site, et pas seulement celle affichée en ligne de commande ?

Sur PrestaShop, regardez Paramètres avancés > Informations. Sur WordPress et WooCommerce, passez par Outils > Santé du site. C’est plus fiable pour le site web que la seule commande php -v. En VPS ou dédié, la version CLI peut différer de celle du front. Il faut donc croiser la version vue dans le CMS, les paquets installés et l’avis du fournisseur.

Mon hébergeur mutualisé a-t-il déjà corrigé la faille, ou est-ce à moi d’agir dans le panneau d’hébergement ?

Les deux points comptent. Un hébergeur mutualisé peut avoir appliqué des correctifs ou des protections sur ses clusters, mais la branche PHP sélectionnée pour votre site reste à vérifier. Si votre panneau client laisse encore votre boutique sur 8.1 ou une branche plus ancienne, vous ne devez pas supposer que tout est réglé. Contrôlez la version utilisée par le site et la communication officielle de l’hébergeur.

Une règle WAF ou la désactivation de session.upload_progress suffit-elle, ou faut-il quand même mettre PHP à jour ?

Il faut quand même mettre PHP à jour. Les avis officiels indiquent que la mise à jour est la seule option sûre. Un WAF peut réduire le risque rapidement, et session.upload_progress.enabled=0 peut limiter une partie du périmètre de CVE-2026-109619, mais ces mesures restent temporaires et incomplètes. Elles servent à gagner du temps, pas à corriger le moteur PHP.

Je suis encore en PHP 8.1, 8.0 ou 7.x : suis-je toujours vulnérable et ai-je un correctif disponible ?

Vous devez considérer ces branches comme à risque tant qu’un correctif ou un backport fournisseur n’est pas explicitement confirmé. Pour 8.1 et avant, il n’y a plus de support upstream. Des rétroportages peuvent exister selon les fournisseurs pour 7.4, 8.0 et 8.1, mais ils restent limités. Sous 7.4, rien n’est annoncé. Sur une boutique ancienne, la vraie difficulté est souvent la compatibilité modules, thème et connecteurs.

Quels signes simples doivent me faire suspecter une compromission avant ou après le patch ?

Tout comportement inhabituel sur une boutique exposée mérite vérification, mais l’absence de symptôme visible ne suffit pas à rassurer. Sur PHP2Shell, le point sensible est aussi la fuite mémoire. Si votre site tournait sur une branche vulnérable, faites contrôler les journaux HTTP et PHP, le mode d’exécution réellement utilisé, puis l’exposition possible des mots de passe, jetons et clés API. Si le doute persiste, prévoyez une rotation des secrets concernés.