Deux failles critiques dans PHP, langage sur lequel repose une grande partie des sites web, ont conduit plusieurs administrations à interrompre préventivement leurs services. Elles peuvent permettre à un attaquant d’exécuter du code à distance sur un serveur vulnérable, sans authentification. Mais les révélations de la PHP Foundation, qui avait entrevu l’un des problèmes dès 2024 sans parvenir à le résoudre, soulèvent une question plus profonde : qui assure la maintenance des composants dont dépend le Web, avec quels moyens, et comment les entreprises peuvent-elles les corriger sans interrompre leurs activités ?
Une vulnérabilité entrevue dès 2024, faute de solution satisfaisante
L’histoire de PHP2Shell ne commence pas avec l’alerte du 21 octobre. Deux ans plus tôt, à la suite d’un audit de sécurité réalisé par Quarkslab, un développeur travaillant pour la PHP Foundation avait identifié les premiers signes d’un problème de gestion de la mémoire, qui sera plus tard associé à CVE-2026-109618. La possibilité d’une exploitation avait été envisagée, sans que les chercheurs parviennent alors à démontrer qu’elle pouvait permettre de prendre le contrôle d’un serveur à distance.
Plusieurs corrections avaient été étudiées, mais toutes présentaient des difficultés : incompatibilités potentielles, risques d’introduire de nouveaux dysfonctionnements ou modifications nécessaires dans de nombreuses extensions. Les discussions se sont prolongées sans décision définitive, au sein d’une équipe où seuls quelques développeurs maîtrisaient suffisamment les mécanismes concernés. Il a fallu attendre août 2026 et les travaux de chercheurs de Calif et d’OpenAI, notamment, pour que la possibilité d’une exécution de code à distance soit établie et que la correction devienne prioritaire.
Dans un billet publié le 21 octobre, la PHP Foundation reconnaît une « défaillance structurelle » de son processus décisionnel, aggravée par le manque de ressources. Elle a depuis engagé une réorganisation de son dispositif de sécurité. Pendant près de deux ans, le traitement d’un problème affectant un composant essentiel du Web est ainsi resté suspendu à la capacité d’une petite équipe à trancher des difficultés techniques particulièrement complexes.
Pour Julian Maurel, CEO de l’éditeur de CMS Jahia, cette affaire interroge directement les garanties offertes aux entreprises par leurs fournisseurs. « Mais lorsqu’un site dépend de nombreux composants, chacun maintenu par des équipes disposant de moyens différents, qui peut réellement garantir que les failles seront corrigées à temps ? »
Des millions d’instances exposées, mais combien réellement vulnérables ?
Palo Alto Networks évoquait, au moment de l’alerte, plus de 22,6 millions d’instances potentiellement vulnérables détectées par Unit 42. Interrogé par Solutions Numériques, Andy Piazza, directeur senior Threat Intelligence précise que ce chiffre correspond aux systèmes exposés exécutant PHP, et non à autant d’installations dont l’exploitabilité aurait été confirmée. Celle-ci dépend notamment de la version utilisée et de la configuration du serveur.
Une étude publiée par Flare le 22 octobre révèle que, sur 2,22 millions d’enregistrements de services divulguant publiquement leur version de PHP, 72,7 % utilisent des branches qui ne bénéficient plus du support officiel du projet. Ces données ne permettent toutefois pas de mesurer la proportion réelle de systèmes vulnérables : plusieurs enregistrements peuvent correspondre à un même serveur, tandis que certains fournisseurs continuent de distribuer des correctifs pour des versions anciennes sans modifier leur numéro apparent.
L’étude relève également la présence de PHP dans des interfaces de VPN, des équipements de stockage, des systèmes de contrôle d’accès physique ou de gestion technique des bâtiments, parfois accessibles sur des ports inhabituels. Autant d’installations qui peuvent échapper aux inventaires centrés sur les applications web classiques.
« Avec PHP2Shell, les entreprises doivent comprendre que la faille se déclenche au cœur du moteur PHP, avant même l’exécution du code applicatif », explique Niv Lanyado, responsable de la recherche en sécurité chez JFrog. Les chercheurs ont notamment démontré ce fonctionnement dans certains environnements Apache. Modifier le code de l’application ne suffit donc pas à supprimer le problème, et les éventuelles mesures d’atténuation restent dépendantes des configurations.
Corriger sans interrompre les services : un arbitrage rarement simple
Pour certaines administrations, la solution a consisté à déconnecter leurs sites en attendant de pouvoir les corriger. Le CERT-EU recommande d’envisager l’isolement des applications exposées lorsqu’une mise à jour immédiate n’est pas possible. Mais interrompre un service essentiel a un coût, tout comme déployer dans l’urgence un correctif dont la compatibilité avec les applications existantes n’a pas été vérifiée. Les tests, les risques de régression et la remise en service des systèmes compliquent des interventions que l’urgence ne permet pas toujours de préparer correctement.
Pour Andy Piazza (Unit 42), l’arbitrage doit tenir compte des conséquences possibles d’une compromission au-delà du seul service exposé. Une interruption peut se justifier si la vulnérabilité permettrait d’accéder à des données sensibles ou d’atteindre d’autres parties du système d’information. Des protections réseau et une surveillance renforcée peuvent réduire temporairement le risque, sans remplacer les correctifs.
Cette succession d’urgences pèse aussi sur les équipes chargées de les gérer. Mandy Andress, CISO d’Elastic, s’inquiète d’une organisation de la sécurité qui exige de traiter chaque nouvelle vulnérabilité comme une catastrophe imminente : « Les files d’attente de patching s’allongent, les avis de sécurité urgents s’accumulent, et l’on demande aux mêmes personnes de traiter chaque alerte comme un exercice d’évacuation d’urgence. »
Pour elle, l’application des correctifs ne peut constituer l’unique rempart. Une meilleure segmentation des réseaux, la réduction de la surface d’attaque et le respect du principe du moindre privilège doivent permettre de limiter les conséquences d’une compromission, y compris lorsqu’un correctif tarde à être déployé.
L’IA accélère la recherche, pas nécessairement la résolution
L’intelligence artificielle a contribué à la découverte de PHP2Shell. Elle explique beaucoup moins bien le désordre qui a entouré sa divulgation. Vincent Strubel, directeur général de l’ANSSI, l’a rappelé dans une publication sur LinkedIn le 22 octobre : « Non, l’IA n’est a priori pour rien dans le caractère chaotique de l’alerte qui prend tout le monde au dépourvu. »
La PHP Foundation décrit une divulgation perturbée par la circulation prématurée d’informations, la publication accidentelle d’une démonstration et la rupture d’un embargo par un distributeur. Checkmarx a également documenté la diffusion de fausses preuves de concept et de recommandations inefficaces, qui ont ajouté à la confusion.
Les annonces d’exploitation ont elles-mêmes nécessité des rectifications. Sophos a retiré, après vérification, une première affirmation faisant état d’une compromission réussie. Le 25 octobre, Unit 42 est également revenu sur un incident qu’il avait initialement associé à PHP2Shell, faute de pouvoir confirmer le vecteur d’accès initial. Des scans et des tentatives d’exploitation ont bien été observés, mais ils ne permettent pas de conclure à une vague de compromissions généralisée.
Dans ses réponses à Solutions Numériques, Andy Piazza (Unit 42) indique que son système NOVA a identifié 14 090 vulnérabilités confirmées dans 3 915 projets open source en deux mois. Une démonstration des capacités de recherche automatisée du fournisseur, qui ne dit toutefois rien du temps nécessaire aux mainteneurs pour examiner ces signalements et produire des correctifs.
Les éditeurs promettent déjà d’accélérer également la défense. Cato Networks affirme ainsi avoir généré en quelques minutes une signature de protection contre PHP2Shell à l’aide d’un agent IA, avant de la faire valider par ses chercheurs. Une démonstration de rapidité qui ne règle cependant pas la question des risques liés à l’automatisation de la défense sur des infrastructures en production.
Vincent Strubel invite précisément à ne pas confondre rapidité et maîtrise : « Les attaquants n’ont souvent que faire des effets de bord de leurs outils, mais les défenseurs doivent toujours se demander si le remède n’est pas pire que le mal. »
