Mise à jour PHP et faille PHP2Shell : le guide pour protéger votre site

C’est ce que l’on appelle la faille PHP2Shell. Elle ne se trouve ni dans WordPress, ni dans PrestaShop, ni dans une extension, mais dans PHP lui-même, le langage qui fait tourner environ 70 % des sites web. La seule protection complète est donc une mise à jour PHP du serveur, et mettre à jour son CMS ne suffit pas.

Ce dossier rassemble ce que les éditeurs et chercheurs en sécurité ont publié depuis (AWS, Automattic, Trellix, Kaspersky, Bitdefender, Sansec, le centre national de cybersécurité néerlandais…), traduit pour les propriétaires de sites et les dirigeants de PME. Vous y trouverez ce qu’est la faille, comment vérifier votre version PHP en deux minutes, qui doit faire la mise à jour selon votre hébergement, quoi faire si elle n’est pas possible tout de suite, comment repérer une attaque et la checklist complète des actions à mener.

PHP2Shell : définition d’une faille qui vise le moteur de votre site

PHP2Shell est le surnom de deux failles critiques du langage PHP, référencées CVE-2026-109618 et CVE-2026-109619 et corrigées le 21 octobre 2026. Elles permettent à un attaquant non authentifié d’exécuter des commandes sur un serveur web à distance, ce que les spécialistes appellent une RCE (exécution de code à distance). Chacune est notée 9,2 sur 10 sur l’échelle de gravité CVSS. Le nom fait écho à Log4Shell, la faille qui avait touché des millions de serveurs Java fin 2021.

Pour comprendre pourquoi c’est sérieux, imaginez un immeuble de bureaux. Votre site, c’est votre bureau : vous avez une bonne serrure (mots de passe robustes), une alarme (extension de sécurité) et vous entretenez vos meubles (mises à jour du CMS). PHP, c’est la porte d’entrée de l’immeuble. Si cette porte a un défaut de fabrication connu de tous, n’importe qui peut entrer dans le bâtiment, sans même passer devant votre bureau.

Ce que fait concrètement la faille

Les deux failles exploitent la manière dont PHP gère sa mémoire quand il traite une requête, en particulier un envoi de formulaire.

• CVE-2026-109618 : une requête volontairement gonflée (par exemple un nom de champ de plusieurs mégaoctets) épuise la mémoire disponible pendant la préparation de la requête. PHP s’interrompt alors en laissant des données à moitié initialisées, que le code de nettoyage traite ensuite comme valides. Cette corruption de mémoire peut être détournée pour exécuter du code.
• CVE-2026-109619 : un processus PHP qui sert plusieurs visiteurs à la suite peut garder une référence vers la mémoire d’une requête précédente, déjà libérée. Une requête suivante bien construite peut s’en servir. Ce chemin passe notamment par le suivi de progression des envois de fichiers, une fonction activée par défaut.

Dans les deux cas, l’attaque se produit avant que le code de votre site ne s’exécute. Votre CMS, votre thème et vos extensions peuvent être parfaitement à jour : ils ne voient même pas passer la requête.

Qui a découvert PHP2Shell ?

Les failles ont été trouvées par les chercheurs de Wiz Research, avec l’aide de modèles d’intelligence artificielle, et signalées à l’équipe de PHP en août 2026. Le correctif a été préparé discrètement pendant deux mois, puis publié de façon coordonnée. C’est un signe des temps : l’IA accélère la découverte des failles, côté défense comme côté attaque, et le délai entre l’annonce d’une faille et son exploitation se compte désormais en heures.

Chronologie : de la découverte aux premières attaques

Les rapports d’AWS, de Trellix et de Kaspersky permettent de retracer les événements. Un point frappe : les attaques ont commencé avant la publication du correctif.

Deux enseignements pour un propriétaire de site. D’abord, attendre la « prochaine maintenance » n’est plus une option pour une faille de ce niveau : Trellix estime que les fenêtres de correction classiques, de 7 ou 30 jours, ne sont plus réalistes pour les systèmes exposés sur Internet. Ensuite, la recherche de traces d’attaque doit remonter au 17 octobre, et pas seulement à la date de l’annonce.

Pourquoi mettre à jour WordPress ne suffit pas

C’est le malentendu le plus répandu, et Automattic, l’entreprise derrière WordPress.com, l’a rappelé dès le 21 octobre : la mise à jour de WordPress, de son thème ou de ses extensions ne corrige pas PHP2Shell. Il faut mettre à jour PHP, c’est-à-dire le moteur installé sur le serveur.

CMS, extensions et PHP : trois couches différentes

Un site se compose de plusieurs couches, entretenues par des personnes différentes :

• Le CMS et ses extensions (WordPress, PrestaShop, Joomla, Drupal, Magento…) : mis à jour depuis l’administration du site, par vous ou par votre prestataire.
• Le langage PHP : installé sur le serveur, mis à jour par l’hébergeur ou par l’administrateur du serveur.
• Le serveur web et le système (Apache, Nginx, LiteSpeed, Linux) : même responsable que PHP.

PHP2Shell se loge dans la deuxième couche. Une extension de sécurité WordPress ou un module anti-piratage PrestaShop n’y peut rien, car la requête malveillante est traitée par PHP avant que l’extension ne démarre. Sansec, spécialiste de la sécurité e-commerce, précise d’ailleurs que son propre pare-feu applicatif ne protège pas contre cette attaque, pour la même raison.

Pour la procédure de mise à jour côté WordPress (sauvegarde, site de test, ordre des mises à jour), nous avons publié un guide pas à pas : comment mettre à jour WordPress et PHP sans casser son site.

Les sites déjà protégés sans action de votre part

Certaines plateformes gèrent PHP pour vous. Automattic indique que les sites hébergés sur WordPress.com, WordPress VIP, WP Cloud ou Pressable sont protégés sans action de leurs propriétaires. Les solutions entièrement hébergées qui ne vous donnent pas accès au serveur, comme Shopify ou Wix, ne relèvent pas de votre responsabilité sur ce point. Pour tous les autres, c’est-à-dire la grande majorité des sites WordPress, WooCommerce, PrestaShop, Joomla ou Drupal installés chez un hébergeur, il faut vérifier.

Faille PHP : quels sites et quelles configurations sont concernés ?

Toutes les versions de PHP qui traitent des requêtes web, de PHP 5.4 à PHP 8.5, sont touchées, quel que soit le CMS. Des exploitations ont été démontrées contre WordPress, Drupal et Joomla, et confirmées sur Magento, Nextcloud et phpMyAdmin selon Trellix. Même une page PHP minimale peut suffire, d’après Automattic.

Le niveau de risque dépend surtout de la façon dont votre serveur exécute PHP. C’est un détail technique, mais il change la priorité :

Le projet PHP désigne Apache avec mod_php comme la configuration la plus exposée, car l’exécution de code y a été démontrée avant même que l’application ne démarre. Les autres modes, dont PHP-FPM, le plus répandu aujourd’hui, restent dans le périmètre officiel. Bitdefender rappelle que l’exploitation n’est pas identique partout, mais qu’aucune configuration n’autorise à reporter la mise à jour.

Les secrets de votre serveur sont aussi en jeu

La faille ne permet pas seulement de prendre la main sur le serveur. Une des deux variantes peut aussi faire fuiter des morceaux de mémoire, où se trouvent parfois des mots de passe de base de données, des clés d’API, des jetons de session ou des clés de chiffrement.

Trellix souligne en outre qu’une exploitation réussie peut être silencieuse : le serveur répond normalement et les journaux de l’application ne montrent rien. C’est pourquoi les spécialistes recommandent de changer les secrets d’un serveur resté exposé, même sans preuve d’intrusion. Notre article sur les clés d’API et mots de passe dans le code explique comment les inventorier et les renouveler.

Comment connaître la version PHP de votre site

Avant toute chose, il faut savoir quelle version PHP fait tourner votre site. Elle s’affiche dans l’administration de la plupart des CMS ou dans l’espace client de votre hébergeur :

Attention au piège de la ligne de commande : sur un serveur, la commande php -v indique la version du PHP utilisé en console, qui n’est pas toujours celle qui sert les pages web. Fiez-vous à la version affichée par le site lui-même.

Vérifiez votre version en un clic

Saisissez le numéro trouvé ci-dessus : l’outil vous indique si votre version contient le correctif PHP2Shell et jusqu’à quand elle sera maintenue.

Un numéro ancien ne veut pas toujours dire « vulnérable »

Les distributions Linux comme Debian, Ubuntu, Red Hat ou AlmaLinux intègrent souvent le correctif dans leurs propres paquets sans changer le numéro de version de PHP. Un serveur peut donc afficher « 8.2.28 » et être corrigé. À l’inverse, un scanner en ligne peut le signaler à tort comme vulnérable. Sur un serveur Debian ou Ubuntu, l’administrateur peut le vérifier dans le journal des modifications du paquet (recherche de « CVE-2026-109618 ») ; sur Red Hat et ses dérivés, avec la commande rpm -q --changelog. Si vous êtes en hébergement mutualisé, la bonne méthode reste de poser la question par écrit à votre hébergeur.

Versions PHP corrigées et dates de fin de vie

Le 21 octobre 2026, le projet PHP a publié une version corrigée pour chacune des quatre branches encore maintenues. Pour les branches abandonnées, il n’a fourni que des correctifs du code source, que seuls certains éditeurs et distributions ont repris.

Quelle version de PHP choisir en 2026 ?

Si vous devez changer de version, autant en profiter pour viser une branche maintenue longtemps. PHP 8.4 et PHP 8.5 reçoivent des correctifs de sécurité jusqu’à fin 2028 et fin 2029 ; ce sont les choix les plus durables, à condition que votre thème et vos extensions soient compatibles. PHP 8.3 reste une option correcte jusqu’à fin 2027. Choisir PHP 8.2 aujourd’hui, c’est s’obliger à refaire la manœuvre dans moins de deux mois.

Le cas des versions abandonnées

VulnCheck estime à plus de 1,1 million le nombre de serveurs exposés sur Internet qui utilisent encore un PHP en fin de vie. Pour eux, trois portes de sortie seulement, selon Trellix : migrer vers une version maintenue, installer un correctif rétroporté par un fournisseur vérifié (certaines distributions et hébergeurs proposent un support étendu), ou déconnecter le système d’Internet.

Sansec signale aussi que l’image Docker officielle de PHP n’est pas corrigée pour les versions 8.1 et antérieures. Si votre site tourne encore en PHP 7.4 ou 8.0, c’est souvent le signe d’un site qui n’a pas été maintenu depuis plusieurs années : la mise à jour PHP impose alors de vérifier le thème, les modules et parfois le code sur mesure, voire d’envisager une migration du site.

Comment faire la mise à jour PHP selon votre hébergement

Qui doit agir ? Tout dépend de la façon dont votre site est hébergé. Malwarebytes le résume bien : la première étape pour un propriétaire de site est d’identifier qui est chargé de mettre à jour son installation PHP.

Hébergement mutualisé ou géré : la bonne question à poser

Sur un hébergement mutualisé, vous ne pouvez pas installer vous-même la version corrigée : c’est l’hébergeur qui met à jour les versions proposées sur ses serveurs. Vous pouvez en revanche choisir, dans votre espace client, la branche utilisée par votre site (8.3, 8.4…). Envoyez à votre hébergeur une question simple, par écrit : « Le correctif PHP2Shell du 21 octobre 2026 est-il appliqué sur la version PHP de mon site, et PHP a-t-il été redémarré depuis ? » Gardez sa réponse : elle vous servira de preuve en cas de problème.

Serveur virtuel ou dédié : mettre à jour, puis redémarrer

Si vous louez un serveur, la mise à jour vous revient, ou revient à votre prestataire. Elle passe par les paquets de votre distribution ou du dépôt utilisé (par exemple deb.sury.org ou Remi), puis par un point souvent oublié : le redémarrage. AWS insiste sur ce détail, car les processus PHP déjà lancés continuent d’utiliser l’ancien code en mémoire tant qu’ils ne sont pas relancés. Il faut donc redémarrer PHP-FPM et le serveur web, puis contrôler la version réellement servie par le site.

Le centre national de cybersécurité néerlandais (NCSC-NL) ajoute un point de vigilance : mettre à jour PHP sur la machine ne met pas à jour le PHP intégré dans les conteneurs, les appliances ou certains logiciels métiers.

Serveurs Windows : la deuxième vague de correctifs

Les serveurs Windows ont connu un épisode supplémentaire. Le 26 octobre, PHP a republié ses versions Windows (8.5.12-1, 8.4.27-1, 8.3.36-1 et 8.2.35-1) pour y intégrer une version corrigée de la bibliothèque de compression Brotli, touchée par une autre faille (CVE-2026-111497). Le numéro affiché par PHP ne change pas : seule la mention « -1 » du paquet téléchargé permet de faire la différence.

Tester le site après la mise à jour

Changer de branche de PHP (par exemple passer de 8.1 à 8.4) peut provoquer des erreurs avec un thème ou une extension ancienne. Une simple mise à jour corrective au sein de la même branche (8.3.30 vers 8.3.36) est en général sans risque, mais un contrôle reste nécessaire : formulaires de contact, envoi de fichiers, tunnel de commande et paiement, espace client, tâches planifiées. Sur un site important, l’idéal est de valider la nouvelle version sur une copie du site, comme nous le détaillons dans notre article sur les mises à jour de site web et le coût de l’attente.

Pas le temps de vérifier votre serveur ou de tester le site après la mise à jour ? Confiez la mise à jour PHP de votre site à notre équipe

Si la mise à jour est impossible tout de suite : les mesures temporaires

Le projet PHP est clair : il n’existe pas de mesure d’atténuation complète, la mise à jour est le seul choix sûr. Si un délai est inévitable (validation interne, dépendance d’un prestataire, vieux site incompatible), ces réglages réduisent le risque pendant quelques jours, à condition d’être appliqués par une personne compétente.

Les réglages de PHP recommandés

• Désactiver le suivi de progression des envois : session.upload_progress.enabled = 0, au niveau du serveur (php.ini, configuration du pool PHP-FPM ou d’Apache), et non dans le code du site ni dans un fichier .user.ini. Ce réglage bloque le chemin principal de CVE-2026-109619 et neutralise aussi CVE-2026-115560. Le projet PHP conseille même de le garder après la mise à jour si vous n’utilisez pas cette fonction.
• Sur PHP 8.5 : désactiver les traces des erreurs fatales (fatal_error_backtraces = 0).
• Limiter la taille des requêtes, le nombre d’en-têtes et de parties de formulaire au niveau du serveur web, du proxy ou du pare-feu.
• Redémarrer tous les processus PHP après chaque modification, sinon le réglage ne s’applique pas.

Certains spécialistes proposent des réglages plus poussés (relancer un processus PHP-FPM à chaque requête, modifier la limite mémoire de PHP), qui ont un coût en performances et doivent être surveillés de près. Trellix et Bitdefender déconseillent en revanche d’utiliser les limites mémoire du système (RLIMIT_AS ou RLIMIT_DATA), qui peuvent au contraire déclencher la faille.

Pare-feu applicatif et blocage des formulaires

Un pare-feu applicatif (WAF), comme ceux de Cloudflare ou d’AWS, peut filtrer une partie des requêtes malveillantes. Il ne corrige pas PHP, et Trellix a observé des attaquants qui modifiaient leurs requêtes dès le 22 octobre pour contourner les règles publiées. Sur un site qui n’accepte aucun envoi de fichier, bloquer les requêtes de type multipart/form-data au niveau du serveur réduit aussi fortement l’exposition. Sur une boutique, cette mesure casse l’envoi d’images produits et parfois certains formulaires de commande : à tester avant de la laisser en place.

Mettre le site hors ligne ?

Certains sites néerlandais se sont mis hors ligne par précaution, et Malwarebytes évoque cette option pour les systèmes qui ne peuvent pas être corrigés. Pour un site vitrine ou une boutique dont l’hébergeur a appliqué le correctif, ce n’est pas nécessaire. C’est en revanche une option raisonnable pour un vieux site en PHP abandonné qui ne sert plus, ou pour un outil interne exposé sans raison sur Internet.

Votre site a-t-il été attaqué ? Les signes à rechercher

Une version vulnérable ne veut pas dire que le site a été piraté. AWS distingue quatre niveaux de preuve qu’il ne faut pas confondre : un serveur exposé, une requête suspecte, une exploitation réussie et une compromission confirmée. Pour trancher, il faut examiner les traces laissées sur le serveur, en remontant au 17 octobre 2026.

Dans les journaux du serveur

• Des requêtes POST de type formulaire inhabituelles, très volumineuses ou répétées en rafale, notamment avec un champ PHP_SESSION_UPLOAD_PROGRESS.
• Des cookies de session anormalement longs.
• Des pics d’erreurs HTTP 500 sur les pages qui reçoivent des formulaires.
• Des erreurs PHP de dépassement mémoire (« Allowed memory size… exhausted ») accompagnées de la mention « Unknown on line 0 ».
• Des outils d’analyse qui se présentent ouvertement, avec un identifiant de navigateur contenant « php2shell ».

Ces traces mesurent surtout des tentatives, pas des réussites. Bitdefender rappelle que leur absence ne suffit pas non plus à écarter une compromission.

Sur le serveur et dans le site

• De nouveaux fichiers PHP dans les dossiers du site, des téléversements ou du cache : c’est la marque classique d’une porte dérobée (web shell).
• Des fichiers exécutables inconnus dans les dossiers temporaires du système.
• Des programmes lancés par PHP ou le serveur web qui n’ont rien à y faire (interpréteur de commandes, outils de téléchargement).
• Des connexions sortantes inexpliquées, une charge processeur anormale, un serveur soudain lent.
• Côté CMS : un administrateur inconnu, des redirections vers d’autres sites, des pages en langue étrangère dans Google.

Les premières charges observées par Trellix étaient des portes dérobées, des logiciels de botnet (Mirai) servant à lancer des attaques par déni de service et un agent d’accès à distance. Un serveur compromis peut donc servir à attaquer d’autres sites sans que son propriétaire ne s’en aperçoive.

Que faire si vous trouvez des traces d’intrusion

1. Conserver les preuves : AWS recommande d’isoler le serveur et de copier les journaux avant de redémarrer, car un redémarrage efface des traces utiles.
2. Corriger PHP et nettoyer, ou mieux, reconstruire le serveur à partir d’une base saine et d’une sauvegarde antérieure à l’intrusion.
3. Changer tous les secrets accessibles au serveur : base de données, clés d’API, accès administrateur, accès FTP et SSH.
4. Évaluer la fuite de données et, si des données personnelles de clients ont pu être consultées, vérifier vos obligations de notification auprès de l’autorité compétente (CNIL en France, PFPDT en Suisse, APD en Belgique, Commission d’accès à l’information au Québec).

Notre guide d’urgence en cas de site piraté détaille ces étapes, et notre enquête sur l’analyse sécurité d’un site web montre comment trancher, preuves à l’appui, entre trafic suspect et vrai piratage.

Un doute sur une intrusion depuis le 17 octobre ? Faites analyser votre serveur par nos experts sécurité

Boutiques en ligne : les points de vigilance de l’e-commerce

Les boutiques WooCommerce, PrestaShop, Magento ou Shopware sont des cibles de choix : elles traitent des commandes, stockent des données clients et accèdent à des comptes de paiement. Sansec, spécialisé dans la sécurité du commerce en ligne, rappelle que leur code peut être parfaitement sain et la boutique tout de même exposée, puisque la faille est dans PHP.

Ses recommandations aux marchands sont pragmatiques :

• Mettre PHP à jour sur chaque serveur de la boutique (site, administration, serveurs annexes). Aucune modification du code de la boutique ne peut corriger la faille.
• Ne pas fermer la boutique si la mise à jour est faite : ce n’est pas nécessaire.
• Tester une vraie commande après toute mesure temporaire, car le blocage des formulaires peut casser le panier, le paiement ou l’ajout d’images produits.
• Surveiller la mémoire du serveur si la limite mémoire de PHP a été modifiée en urgence, et la rétablir après la mise à jour.

Sansec apporte aussi une nuance utile : selon ses analyses, les preuves de concept publiques ne fonctionnent pas sur une installation PHP par défaut et exigent généralement une autre faille dans l’application. Il juge donc une exploitation de masse moins probable qu’annoncé. Ce désaccord entre spécialistes ne change rien à la conclusion : la mise à jour PHP reste obligatoire, mais il n’y a pas lieu de céder à la panique. Pour aller plus loin, consultez notre dossier sur les incidents de maintenance e-commerce les plus fréquents.

État de la menace deux semaines après le correctif

Kaspersky a dressé un premier bilan fin octobre. Il dessine une menace bien réelle, mais pas encore la catastrophe annoncée.

• Des attaques confirmées : premières tentatives dès le 17 octobre, exploitation confirmée sur un serveur piège le 24 octobre, inscription au catalogue des failles activement exploitées de la CISA le 26 octobre.
• Des cibles inattendues : des pare-feux et serveurs d’administration qui embarquent PHP ont été compromis, parfois en combinaison avec une faille du noyau Linux. La faille ne concerne donc pas que les sites web.
• Un retard de correction massif : environ 29 millions de serveurs sur les 46 millions repérés par Censys restaient vulnérables.
• Pas de vague de piratages massive confirmée à ce stade, et aucun groupe de rançongiciel identifié, selon Kaspersky et Trellix.

Deux failles voisines à connaître

• CVE-2026-115560, annoncée le 23 octobre : une autre faille d’exécution de code liée au suivi des envois de fichiers, qui ne touche que des sites aux réglages de session inhabituels. Elle sera corrigée lors d’une prochaine version courante de PHP ; en attendant, le réglage session.upload_progress.enabled = 0 suffit à la bloquer.
• CVE-2026-111497 : une faille de la bibliothèque Brotli, utilisée pour décompresser certaines réponses web. Elle concerne les versions Windows de PHP, corrigées par les paquets « -1 », et les sites qui décompressent automatiquement les réponses d’autres serveurs.

Ce que PHP2Shell change pour les dirigeants de PME

Les analyses de Trellix et de Fortinet, écrites pour les équipes de sécurité, contiennent un message qui concerne directement les dirigeants : la sécurité d’un site ne s’arrête pas à son CMS.

Le temps de réaction se compte en heures

Le 21 octobre, des portes dérobées et des logiciels de botnet circulaient l’après-midi même de la publication du correctif. Une entreprise qui attend le passage mensuel de son prestataire, ou qui découvre la faille en lisant la presse une semaine plus tard, laisse son serveur ouvert pendant la période la plus dangereuse.

Un risque business, pas seulement technique

Un serveur pris en main par un attaquant, c’est potentiellement :

• un site défiguré, redirigé vers des sites frauduleux ou signalé comme dangereux par Google, avec une perte de trafic et de référencement ;
• des données clients consultées ou copiées, avec des obligations de notification et une perte de confiance ;
• un serveur utilisé pour attaquer d’autres sites ou envoyer du spam, et une adresse IP blacklistée qui bloque vos propres e-mails ;
• des jours d’indisponibilité et une facture de nettoyage bien supérieure au coût d’une maintenance préventive.

Faire l’inventaire de ce qui tourne sous PHP

Le centre national de cybersécurité néerlandais recommande de commencer par l’inventaire des applications PHP, en priorisant celles qui sont exposées sur Internet. Dans une PME, la liste est souvent plus longue qu’on ne le pense : site vitrine, boutique, ancien site d’une marque, extranet client, outil de réservation, phpMyAdmin, intranet… Les sites oubliés, qui ne sont plus entretenus par personne, sont les plus exposés. Ce sont aussi ceux qui génèrent des pannes silencieuses que personne ne remarque avant qu’il ne soit trop tard.

Idées reçues sur la faille PHP2Shell

• « Mon WordPress est à jour, je suis protégé. » Faux : la faille est dans PHP, pas dans WordPress.
• « J’ai une extension de sécurité, elle bloquera l’attaque. » Faux : l’attaque se produit avant que l’extension ne démarre.
• « Mon site est trop petit pour intéresser les pirates. » Faux : les attaques sont automatisées, des robots testent tous les serveurs accessibles, quelle que soit leur taille.
• « Un pare-feu applicatif suffit. » Faux : il réduit le risque, mais les attaquants adaptent leurs requêtes pour le contourner.
• « Mon numéro de version est ancien, je suis forcément vulnérable. » Pas toujours : certaines distributions corrigent sans changer le numéro. Il faut vérifier auprès de l’hébergeur.
• « La mise à jour est faite, le sujet est clos. » Pas tout à fait : il faut redémarrer PHP, vérifier l’absence d’intrusion depuis le 17 octobre et prévoir la fin de vie de PHP 8.2.

Checklist PHP2Shell : les 10 actions à mener

Cette checklist s’inspire des recommandations officielles du projet PHP et du centre national de cybersécurité néerlandais, complétées par celles d’AWS, de Trellix et de Bitdefender. Cochez les actions au fur et à mesure.

Si plusieurs cases restent vides parce que vous ne savez pas comment les vérifier, c’est normal : la plupart demandent un accès au serveur et quelques compétences d’administration. C’est exactement le rôle d’un prestataire de maintenance.

Pourquoi un contrat de maintenance change tout face à une faille comme PHP2Shell

PHP2Shell n’est pas un cas isolé. Chaque année, plusieurs failles critiques touchent PHP, les CMS, les extensions ou les bibliothèques qu’ils utilisent. Ce qui fait la différence, ce n’est pas la faille, c’est le temps de réaction et la méthode.

Un contrat de maintenance web sérieux couvre précisément ce qui a manqué à de nombreux sites en octobre :

• Une veille de sécurité qui repère l’annonce d’une faille avant qu’elle ne fasse la une, et un plan d’action prêt le jour du correctif.
• La mise à jour de toutes les couches : CMS, extensions, thème, mais aussi PHP et le serveur, avec un redémarrage et un contrôle de la version réellement servie.
• Des tests après chaque mise à jour : formulaires, commandes, paiement, espace client.
• Des sauvegardes vérifiées, conservées hors du serveur, pour revenir en arrière en cas de problème ou d’intrusion.
• Une surveillance continue : disponibilité, fichiers modifiés, comptes créés, alertes de Google Search Console.
• La planification des montées de version : sortir de PHP 8.2 avant le 31 décembre 2026, préparer PHP 8.4 ou 8.5, sans interruption de service. Pour un changement d’hébergeur, notre méthode est détaillée dans l’article sur la migration d’hébergement sans coupure.

PHP2Shell en est l’illustration : quelques heures après la publication du correctif, le 21 octobre 2026, tous les sites de nos clients sous contrat de maintenance tournaient déjà sur une version de PHP corrigée, sans qu’ils aient eu à le demander. Notre veille de sécurité a repéré l’alerte, notre équipe a mis PHP à jour, redémarré les serveurs et vérifié chaque site.

Chez Aurone, nos contrats de maintenance prévoient une intervention sous 24 heures, et sous une heure pour les urgences de sécurité, sur WordPress, WooCommerce, PrestaShop et les autres CMS. Pour les sites WordPress, notre offre de maintenance WordPress intègre le suivi de la version PHP ; pour les boutiques, la maintenance PrestaShop couvre aussi les modules et le serveur.

Conclusion : la mise à jour PHP, un réflexe à garder

PHP2Shell rappelle une réalité que beaucoup de propriétaires de sites découvrent à cette occasion : sous chaque site, il y a un langage, un serveur et des réglages, et tous ont besoin d’un suivi. La bonne nouvelle, c’est que la parade est simple quand elle est anticipée : vérifier sa version, faire appliquer la mise à jour PHP, redémarrer, contrôler, puis planifier les prochaines montées de version.

Si vous n’avez pas encore vérifié votre site, faites-le aujourd’hui avec l’outil de ce dossier. Si la réponse est « vulnérable », « abandonnée » ou « je ne sais pas », ne restez pas seul face au problème.

Questions fréquentes sur la mise à jour PHP et la faille PHP2Shell

Qu’est-ce que la faille PHP2Shell ?

PHP2Shell est le surnom de deux failles critiques du langage PHP, CVE-2026-109618 et CVE-2026-109619, corrigées le 21 octobre 2026 et notées 9,2 sur 10. Elles permettent à un attaquant d’exécuter des commandes sur un serveur web à distance, sans identifiant ni mot de passe, en exploitant la gestion de la mémoire de PHP lors du traitement d’une requête. Toutes les versions de PHP 5.4 à 8.5 qui servent des pages web sont concernées. La seule protection complète est la mise à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

Mettre à jour WordPress suffit-il à se protéger de PHP2Shell ?

Non. La faille se trouve dans PHP, le moteur installé sur le serveur, et non dans WordPress, son thème ou ses extensions. Mettre à jour WordPress reste indispensable pour d’autres raisons, mais seule une mise à jour PHP corrige PHP2Shell. Sur un hébergement mutualisé ou géré, c’est l’hébergeur qui l’applique : demandez-lui une confirmation écrite.

Comment savoir quelle version de PHP utilise mon site ?

Dans WordPress, la version de PHP s’affiche dans Outils, Santé du site, onglet Informations, section Serveur. Dans PrestaShop, elle se trouve dans Paramètres avancés, Informations, et dans Joomla dans Système, Informations système. Vous pouvez aussi la consulter dans l’espace client de votre hébergeur, rubrique « Version PHP ». Notez le numéro complet, avec ses trois nombres, pour savoir s’il contient le correctif.

Quelle version de PHP choisir en 2026 ?

En 2026, les versions les plus durables sont PHP 8.4, maintenue jusqu’au 31 décembre 2028, et PHP 8.5, maintenue jusqu’au 31 décembre 2029. PHP 8.3 reste correcte jusqu’à fin 2027. PHP 8.2 cessera de recevoir des correctifs le 31 décembre 2026 et PHP 8.1 n’en reçoit déjà plus. Avant de changer de branche, vérifiez la compatibilité de votre thème et de vos extensions sur une copie du site.

La mise à jour PHP peut-elle casser mon site ?

Une mise à jour corrective dans la même branche, par exemple de 8.3.30 à 8.3.36, est en général sans risque pour le site. Un changement de branche, comme le passage de PHP 8.1 à 8.4, peut en revanche provoquer des erreurs avec un thème, une extension ou un code sur mesure ancien. Il faut donc faire une sauvegarde, tester la nouvelle version sur une copie du site, puis vérifier les formulaires, le paiement et l’espace client après la mise en production.

Mon hébergeur s’occupe-t-il de la mise à jour PHP ?

Sur un hébergement mutualisé ou géré, l’hébergeur met à jour les versions de PHP proposées sur ses serveurs, mais c’est souvent à vous de choisir la branche utilisée par votre site. Sur un serveur virtuel ou dédié, la mise à jour revient au client ou à son prestataire de maintenance. Dans tous les cas, demandez par écrit si le correctif PHP2Shell du 21 octobre 2026 est appliqué et si PHP a été redémarré depuis.

Nos sources

• AWS, PHP2Shell: Inside the Critical PHP Vulnerabilities That Put Web Servers at Risk
• Automattic, Your Sites Are Protected Against the PHP2Shell Vulnerabilities (21 octobre 2026)
• Acer, PHP2Shell Explained: What the PHP Vulnerability Means for You
• Trellix, PHP2Shell: What defenders need to know
• Kaspersky, PHP2Shell: what we know about the threat two weeks later
• Bitdefender, Technical Advisory: PHP2Shell Pre-Auth RCE
• Sansec, PHP2Shell: PHP RCE
• NCSC-NL (centre national de cybersécurité des Pays-Bas), php2shell
• Projet PHP, annonce de PHP 8.4.27 (21 octobre 2026)
• php.net, versions de PHP prises en charge
• The Hacker News, PHP issues second Windows security update (Brotli, CVE-2026-111497)
• IT-Connect, PHP signale une nouvelle faille RCE (CVE-2026-115560)
• Malwarebytes, PHP2Shell : pourquoi des sites sont mis hors ligne