Nous savons que cela a entraîné des dysfonctionnements sur certains sites web, et nous comprenons à quel point cela peut être frustrant. Cet article explique en quoi consistent ces failles de sécurité, pourquoi nous avons agi de la sorte, pourquoi nous ne pouvons pas réactiver les anciennes versions de PHP, et ce que vous devez faire pour que votre site web fonctionne à nouveau.
Le 21 octobre 2026, l'équipe de développement de PHP a publié des mises à jour de sécurité d'urgence concernant deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619. Ces deux failles permettent l'exécution de code à distance : un attaquant peut exécuter son propre code sur un serveur web sans avoir à se connecter ni à disposer d'un compte sur celui-ci.
Ce qui rend PHP2Shell (le nom donné à cette paire d'exploits) particulièrement dangereux, c'est le timing : des tentatives d'exploitation avaient déjà été observées au moment même où les vulnérabilités ont été rendues publiques, et des techniques d'attaque efficaces circulaient peu après.
Il n'y avait aucun moment où un serveur pouvait être considéré comme sûr en attendant un créneau de maintenance approprié.
La réaction de la communauté de la sécurité a reflété cette urgence. Le CERT-EU a publié l’avis de sécurité 2026-018, recommandant l’application immédiate d’un correctif ou l’isolation des systèmes exposés. L’ENISA, en collaboration avec la Commission européenne, le CERT-EU, Europol et le réseau européen des CSIRT, a publié une déclaration commune appelant à une action immédiate. Le CIRCL luxembourgeois a publié l’avis TR-102 confirmant le niveau de gravité « critique ». La NSA a publié son propre avis le même jour. Vous trouverez les liens vers tous ces documents à la fin de cet article.
La plupart des avis de sécurité adressés aux propriétaires de sites web concernent une application spécifique : un plugin WordPress, une extension Joomla, un système de boutique en ligne. La solution consiste généralement à mettre à jour ce composant précis. PHP2Shell va plus loin. La faille se trouve dans le moteur d'exécution PHP lui-même, c'est-à-dire le moteur qui exécute toutes les applications PHP sur nos serveurs.
Un site web peut donc être parfaitement à jour au niveau de l'application tout en restant vulnérable. Un site WordPress dont tous les plugins ont été mis à jour, un site Drupal fonctionnant sous la dernière version, une application sur mesure qui n'a jamais connu de problème de sécurité : tous sont exposés si la version de PHP sous-jacente n'a pas été corrigée.
Comme c'est nous qui fournissons les versions de PHP sur nos serveurs, c'était à nous de résoudre ce problème, et nous ne pouvions pas attendre que les propriétaires de sites web s'en chargent individuellement. Nous avons donc dû agir.
Quelques heures seulement après la divulgation de cette faille, nous avons mis à jour toutes les versions de PHP prises en charge sur l'ensemble de nos serveurs Plesk en installant les versions corrigées. Pour les clients utilisant une version récente de PHP, l'affaire s'est arrêtée là : rien n'a changé et aucune intervention n'a été nécessaire.
Pour les versions de PHP ayant déjà atteint leur fin de vie, aucun correctif n'était disponible. L'équipe PHP ne assure plus la maintenance de ces branches, et aucun correctif pour PHP2Shell n'existe pour celles-ci. Chacune des versions concernées était en fin de vie depuis au moins dix mois. Nos seules options étaient soit de laisser des vulnérabilités connues et activement exploitées en place sur notre infrastructure, soit de désactiver ces versions. Nous les avons désactivées.
Nous avons agi ainsi sans préavis, et c'était un choix délibéré. Les attaques avaient déjà commencé. Annoncer une désactivation une semaine à l'avance aurait signifié une semaine durant laquelle chaque site obsolète de notre plateforme aurait constitué une cible facile, et au cours de laquelle l'annonce elle-même aurait indiqué aux pirates exactement où chercher.
Depuis la désactivation, nous avons reçu des demandes visant à réactiver une ancienne version de PHP pour un seul compte, souvent pour de bonnes raisons : une application héritée qui ne peut pas être mise à jour rapidement, une agence qui a cessé son activité, une migration déjà prévue pour le trimestre prochain. Nous comprenons chacune de ces situations, mais nous les refusons toutes.
En effet, dans le cadre d'un hébergement mutualisé, une vulnérabilité ne se limite jamais à un seul site web. Un seul processus PHP compromis sur un serveur constitue un point d'ancrage à partir duquel un pirate peut explorer tous les autres éléments qui y sont exécutés. Le fait de maintenir une version obsolète pour un seul client mettrait en danger tous les autres clients de ce serveur, y compris ceux qui ont pris toutes les précautions nécessaires.
Nous tenons également à préciser ce que nous prenons en compte. Un site web temporairement indisponible en raison d’une mise à jour PHP nécessaire constitue un désagrément dont la solution est connue. Un site web qui a été piraté peut entraîner le vol de données clients, la défiguration de pages, la diffusion de logiciels malveillants aux visiteurs, l’inscription sur la liste noire des moteurs de recherche et, au regard du RGPD, une violation de données devant être signalée. Entre les deux, nous choisirons sans hésiter le simple désagrément.
Cela vaut également pour l'avenir. Nous ne maintiendrons plus les versions de PHP arrivées en fin de vie sur notre plateforme. Il existe certes un support de sécurité prolongé assuré par des tiers pour certaines anciennes branches, mais celui-ci n'offre pas les mêmes garanties qu'une version officiellement prise en charge, et PHP2Shell a démontré à quelle vitesse un environnement d'exécution non corrigé peut devenir un risque.
Si votre site web a cessé de fonctionner à partir du 21 octobre, il est très probable qu'il utilise une version de PHP qui n'est plus prise en charge. Pour résoudre ce problème, vous devez passer à une version prise en charge. Dans Plesk, accédez à « Sites web et domaines », ouvrez les « Paramètres PHP » du domaine concerné, puis sélectionnez une version dans la liste ci-dessous.
Deux points à retenir :
PHP2Shell ne sera pas la dernière vulnérabilité de ce type. Le projet PHP publie un calendrier de support clair pour chaque version, et le schéma est toujours le même : une branche bénéficie d’un support actif pendant deux ans et de correctifs de sécurité pendant deux ans supplémentaires, puis plus rien. Les sites web qui restent dans cette période bénéficient de correctifs dans les heures qui suivent la divulgation d’une faille. Ceux qui en sont exclus n’en bénéficient pas, et l’écart entre les deux n’a jamais été aussi flagrant qu’il ne l’a été cette semaine.
Notre recommandation est simple. Maintenez votre site web sur une version de PHP qui bénéficie encore de mises à jour de sécurité, considérez la mise à niveau vers la version suivante comme une opération de maintenance courante plutôt que comme un projet à part entière, et veillez à ce que votre CMS, vos thèmes et vos plugins soient à jour afin que la mise à niveau se déroule sans encombre. Nous continuerons à proposer toutes les branches PHP actuellement prises en charge, mais nous ne proposerons plus les versions dont la fin de vie officielle a été annoncée.
Découvrez la meilleure connexion Internet pour regarder la télévision en streaming grâce à des conseils pratiques sur le débit, la stabilité, le Wi-Fi et la consommation de données, afin de pouvoir profiter du streaming dans toutes les pièces sans aucun souci.
Qu'est-ce que la résidence locale des données ? Découvrez en quoi le stockage des données sur le territoire national influe sur la conformité, la latence, le contrôle, la reprise après sinistre et la confiance des clients pour les entreprises.
