Le 21 octobre 2026, deux vulnérabilités critiques affectant PHP provoquent une mobilisation inhabituelle des autorités européennes de cybersécurité. Les failles CVE-2026-109618 et CVE-2026-109619 permettent, dans certaines conditions, l’exécution de code à distance sans authentification. Mais derrière cette alerte se trouve une histoire plus complexe : « un problème technique identifié dès 2024, des correctifs longtemps retardés, une divulgation perturbée par plusieurs fuites et des tentatives d’exploitation détectées avant la publication officielle. »
Dans une publication particulièrement transparente, la PHP Foundation revient elle-même sur cette succession d’événements et reconnaît des défaillances dans l’organisation de ses travaux de sécurité. L’affaire PHP2Shell dépasse ainsi le cadre d’une nouvelle alerte sur des vulnérabilités critiques. Elle interroge la capacité d’un projet open source majeur à traiter des faiblesses complexes, à coordonner leur divulgation et à mobiliser les ressources nécessaires à leur correction.
2024 : une faiblesse détectée, mais sans exploitation démontrée
L’histoire commence en 2024, lors d’un audit de sécurité de PHP réalisé par Quarkslab, organisé par l’Open Source Technology Improvement Fund (OSTIF) et financé grâce au soutien de la Sovereign Tech Agency allemande.
En travaillant sur la correction d’un problème signalé durant cet audit, un développeur du cœur de PHP identifie une anomalie dans la gestion des situations d’épuisement de mémoire, ou *out-of-memory* (OOM). Le moteur PHP peut, dans certaines circonstances, interrompre brutalement une opération alors que des structures internes ne sont que partiellement initialisées. Leur traitement ultérieur risque alors de provoquer une corruption mémoire.
Dès 2024, l’équipe envisage la possibilité d’une exploitation de cette faiblesse. Toutefois, aucun chemin d’attaque concret permettant une exécution de code à distance n’est alors démontré. La difficulté réside également dans la correction. Plusieurs approches sont étudiées, mais chacune présente des conséquences potentiellement importantes : rupture de compatibilité, introduction de nouveaux risques de déni de service ou nécessité de modifier de nombreuses extensions tierces.
Le fonctionnement collégial de l’équipe de sécurité, fondé sur la recherche d’un consensus, complique la prise de décision. Les travaux sont successivement interrompus puis repris, sans aboutir à une solution.
La PHP Foundation reconnaît aujourd’hui que cette situation relevait d’une défaillance structurelle, associant un processus décisionnel inadapté et un manque de développeurs disposant d’une connaissance approfondie du moteur PHP.
« Le problème n’était donc pas ignoré. Il était identifié, mais son traitement restait bloqué par des arbitrages techniques et organisationnels. »
Août 2026 : les chercheurs démontrent la gravité du problème
La situation évolue durant l’été 2026.
Dans le cadre du programme « Patch the Planet », auquel participe la PHP Foundation, la société Calif commence un audit approfondi de PHP le 30 juillet. Le 11 août, un chercheur de Calif signale une possibilité d’exécution de code à distance reposant sur la même cause fondamentale que celle identifiée deux ans auparavant.
OpenAI rapporte indépendamment un problème ayant cette même origine. Wiz Research identifie également plusieurs vecteurs d’attaque, notamment dans des environnements utilisant WordPress et Drupal. Les découvertes successives permettent de comprendre que le défaut ne concerne pas seulement une anomalie théorique de gestion mémoire, il peut effectivement être exploité pour compromettre un serveur.
La PHP Foundation fait alors de sa correction une priorité absolue. Plusieurs chercheurs et développeurs travaillent conjointement à la conception des correctifs, à leur validation et à leur adaptation aux différentes branches de PHP. L’affaire met en évidence un paradoxe : la gravité de la vulnérabilité devient pleinement démontrable grâce à la multiplication des recherches indépendantes, alors que les ressources disponibles pour produire et maintenir les corrections restent limitées.
Deux vulnérabilités dans des mécanismes fondamentaux de PHP
Les vulnérabilités finalement publiées présentent des mécanismes distincts, mais concernent toutes deux la gestion de la mémoire et de l’état interne des requêtes.
La première, CVE-2026-109618, repose sur une corruption mémoire pouvant survenir lorsque PHP atteint une limite d’allocation à un moment particulier du traitement d’une requête. La seconde, CVE-2026-109619, concerne la persistance d’un état interne devenu invalide après une erreur fatale. Des références à une zone mémoire libérée peuvent alors être réutilisées lors du traitement d’une autre requête.
Dans les deux cas, les conséquences potentielles comprennent une exécution de code à distance. Les vulnérabilités reçoivent chacune un score CVSS v4.0 de 9,2. Leur portée est importante parce qu’elles affectent des mécanismes internes à PHP, indépendamment d’une vulnérabilité propre à une application particulière. Les environnements utilisant PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed peuvent être concernés.
Les conditions d’exploitation varient néanmoins selon les configurations. L’équipe PHP considère notamment les installations utilisant mod_php comme particulièrement exposées, une exploitation sans authentification ayant été démontrée avant même l’exécution du code applicatif.
17 octobre : des tentatives d’exploitation avant la divulgation
Un événement découvert rétrospectivement par Amazon Threat Intelligence ajoute une dimension supplémentaire à cette chronologie. L’analyse des données de son réseau de leurres MadPot révèle une tentative d’exploitation de PHP2Shell remontant au 17 octobre, soit quatre jours avant la publication officielle des vulnérabilités.
La tentative provient d’une adresse IP associée à un service commercial d’anonymisation. Amazon ne peut cependant pas établir comment son auteur a obtenu les informations nécessaires à cette tentative. Il serait donc excessif d’affirmer que la fuite publique des jours suivants est à l’origine de cette activité. Les premières tentatives observées lui sont antérieures.
L’observation ne prouve pas non plus qu’un véritable serveur de production ait été compromis à cette date. Elle montre néanmoins que des activités suspectes correspondant aux vulnérabilités existaient avant leur divulgation officielle. Ce constat remet en question une hypothèse encore fréquente dans la gestion des vulnérabilités : considérer que le risque d’exploitation ne devient significatif qu’après la publication d’un avis de sécurité ou d’un correctif.
20 octobre : une première fuite bouleverse le calendrier
La publication coordonnée était initialement prévue pour le 22 octobre à 14 heures UTC.
Les distributeurs avaient reçu les correctifs sous embargo afin de préparer les mises à jour et de permettre leur diffusion au moment de la divulgation publique, mais le 20 octobre, vers 15 heures UTC, les identifiants des deux CVE commencent à circuler sur des forums et des réseaux sociaux.
Les informations diffusées comportent notamment un score CVSS erroné de 10 sur 10 et une date de publication incorrecte. Selon la PHP Foundation, aucun détail technique permettant directement l’exploitation n’est alors divulgué. Face à cette circulation prématurée d’informations, le projet décide d’anticiper son annonce et d’avancer au 21 octobre la publication des correctifs.
Une diffusion immédiate aurait présenté un autre problème : de nombreux distributeurs n’auraient pas encore disposé de paquets prêts à être installés. La décision cherche donc à concilier deux impératifs contradictoires, réduire la période d’exposition des utilisateurs tout en leur donnant effectivement les moyens d’appliquer les corrections.
Une vidéo publiée par erreur aggrave la situation
La situation se complique quelques heures plus tard.
À la suite de cette modification du calendrier, Calif publie accidentellement une vidéo présentant une démonstration d’exploitation des vulnérabilités sur plusieurs cibles. La vidéo est rapidement supprimée, mais des copies commencent à circuler. Contrairement à la première fuite, limitée essentiellement aux identifiants CVE, cette publication révèle certains éléments techniques supplémentaires, même s’ils restent partiels.
La PHP Foundation estime qu’elle a contribué à accélérer le développement de plusieurs preuves de concept. Des recommandations de mitigation communiquées à certains opérateurs d’infrastructures critiques pourraient également avoir circulé prématurément, sans que cette seconde fuite soit formellement établie.
« La divulgation coordonnée devient alors difficile à maîtriser, Chaque information supplémentaire peut aider les défenseurs à se préparer, mais également faciliter le travail des attaquants. »
21 octobre : la rupture de l’embargo provoque une controverse
Le 21 octobre, à 7 h 41 UTC, l’entreprise Chainguard publie des images logicielles contenant les correctifs, plus de six heures avant l’heure prévue pour la divulgation coordonnée.
La PHP Foundation dénonce une rupture unilatérale de l’embargo. Elle souligne qu’un attaquant pourrait examiner les différences entre les versions corrigées et vulnérables pour comprendre le mécanisme des failles, alors qu’une grande partie des utilisateurs attend encore la publication officielle des mises à jour.
Chainguard défend une autre appréciation de la situation. Son dirigeant, Dan Lorenc, explique que la décision de publier les images corrigées a notamment été motivée par des signalements d’exploitation active et par la quantité d’informations déjà disponibles sur les vulnérabilités.
Selon cette lecture, maintenir strictement l’embargo alors que des tentatives d’exploitation étaient signalées aurait également exposé les utilisateurs à un risque.
La controverse illustre une difficulté fondamentale de la divulgation coordonnée. Tant que les informations restent confidentielles, une publication simultanée des correctifs peut protéger l’écosystème. Mais lorsque des indices d’exploitation apparaissent avant l’échéance, le maintien du calendrier devient lui-même un choix de sécurité discutable. Il n’existe alors pas nécessairement de solution permettant de protéger tous les acteurs dans les mêmes conditions.
Une mobilisation européenne exceptionnelle
Le 21 octobre, PHP publie finalement quatre versions correctives : 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
Le même jour, la Commission européenne, l’ENISA, CERT-EU, Europol EC3 et le réseau européen des CSIRT publient une déclaration commune appelant les organisations à agir immédiatement. Cette mobilisation collective souligne les risques associés à la présence de PHP dans une grande diversité de services numériques, y compris lorsqu’il est intégré à des applications ou à des produits tiers.
Les autorités recommandent notamment d’identifier les applications concernées, de coordonner les mises à jour avec les hébergeurs et les fournisseurs, et de traiter prioritairement les systèmes exposés à Internet.
Lorsque les correctifs ne peuvent pas être appliqués immédiatement, l’isolement temporaire des applications exposées peut devenir nécessaire. Les mécanismes de protection intermédiaires, notamment les règles de pare-feu applicatif, peuvent réduire certains chemins d’exploitation. Ils ne remplacent cependant pas les corrections du moteur PHP.
Le 23 octobre, un nouvel avis vient compléter cette séquence.
La vulnérabilité CVE-2026-115560 concerne un scénario particulier impliquant la gestion des sessions et des téléversements de fichiers. Son exploitation nécessite une combinaison inhabituelle de paramètres et de code applicatif.
Le projet PHP recommande, pour les configurations concernées, de désactiver temporairement `session.upload_progress.enabled` en attendant le correctif prévu dans une prochaine version régulière. Cette troisième vulnérabilité doit être distinguée des deux failles critiques initialement publiées.
Au-delà des correctifs, la question des moyens consacrés à la sécurité
L’un des enseignements les plus importants de PHP2Shell se trouve dans les déclarations de la PHP Foundation. Le projet reconnaît que ses mécanismes de décision et le nombre limité de développeurs maîtrisant les composants internes du langage ont contribué à retarder la résolution d’un problème complexe.
Il annonce une évolution de ses processus, notamment pour faciliter les arbitrages lorsque plusieurs solutions techniques présentent des inconvénients importants. La fondation souligne également que les outils de recherche automatisée et l’intelligence artificielle augmentent le volume des signalements de vulnérabilités. Cette progression améliore les possibilités de découverte, mais elle ne supprime pas le travail nécessaire pour vérifier les résultats, concevoir les correctifs et maintenir la compatibilité des logiciels. Au contraire, elle peut accentuer la pression sur des équipes disposant de ressources limitées.
Le cas PHP2Shell montre ainsi qu’identifier une vulnérabilité ne constitue qu’une partie du problème. Il faut ensuite disposer des compétences, des moyens et d’une organisation capable de décider, de corriger et de diffuser les mises à jour dans des délais adaptés à la gravité du risque.
La mobilisation des autorités européennes rappelle également que la sécurité des composants logiciels largement diffusés ne concerne pas uniquement leurs mainteneurs. Elle engage les éditeurs, les fournisseurs de services, les hébergeurs et les organisations qui en dépendent.
« L’affaire PHP2Shell révèle finalement deux fragilités complémentaires : une vulnérabilité technique dont la correction a été retardée et un processus de divulgation devenu instable lorsque la confidentialité des informations n’a plus pu être garantie. »
La rapidité de publication des correctifs reste essentielle. Mais cette crise rappelle surtout que la sécurité d’un composant aussi largement utilisé que PHP dépend d’un travail continu, bien avant qu’une vulnérabilité ne fasse l’objet d’une alerte publique.
