Secu
PHP2Shell : le mea culpa de la PHP Foundation dévoile une faille bien au-delà du code source…
Par Laurent Delattre, publié le 27 octobre 2026
Après la bérézina de la semaine dernière et la panique engendrée par la divulgation de deux failles PHP majeures, la PHP Foundation publie un billet qui sonne comme un mea culpa. Elle admet avoir laissé un problème repéré dès 2024 sans correctif, faute d’en mesurer la gravité. Seules les recherches menées avec l’IA ont fini par la démontrer. Entre arbitrages bloqués, fuites en cascade et embargo rompu, l’histoire de PHP2Shell en dit long sur la fragilité de nos écosystèmes numériques et sur l’immensité des chantiers de réparation engendrés par l’IA…
Reconnaissons-le : rarement un projet, open source ou pas, aura exposé ses propres errements avec autant de franchise. Publié le jour de la divulgation de la faille, mais un peu perdu dans le brouhaha des derniers jours, le billet de la PHP Foundation ne s’attarde ni sur les deux failles PHP2Shell, que nous avons largement détaillées, ni sur la marche à suivre pour mettre à jour ses serveurs. Il raconte en réalité une tout autre histoire : celle d’un échec collectif : comment ces vulnérabilités ont été trouvées, pourquoi leur correction a tant tardé, et comment le secret a fini par fuiter.
Une faille entrevue en 2024, un correctif englué dans les arbitrages
Tout commence par un audit. En 2024, la Sovereign Tech Agency allemande a financé le premier audit de sécurité externe de PHP depuis plusieurs années. L’OSTIF en a assuré l’organisation et Quarkslab la réalisation. En corrigeant l’un des défauts remontés par les auditeurs, un développeur du noyau PHP missionné par la fondation a repéré les premiers signes d’un problème de gestion de la mémoire en cas de saturation (OOM, pour « out of memory »), celui-là même qui donnera naissance à la CVE-2026-109618. Une exploitation a bien été théorisée à l’époque, mais aucun vecteur concret n’a été identifié, et d’autres failles à l’impact immédiat ont relégué ce problème au second plan.
Le plus instructif vient ensuite. Pour corriger ce défaut, l’équipe de sécurité de PHP a mis au point plusieurs approches concurrentes, chacune avec ses contreparties : ruptures de compatibilité, nouvelles possibilités de déni de service, ou modifications de nombreuses extensions tierces dont la coordination paraissait hors de portée. Fonctionnant au consensus, l’équipe n’est pas parvenue à trancher, de peur de livrer le mauvais choix. Faute de piste connue pour une exécution de code à distance, et les rares développeurs connaissant suffisamment bien le moteur étant occupés ailleurs, les travaux ont stagné pendant des mois. La fondation ne cherche pas à enjoliver les choses : elle parle d’« un échec structurel », imputable à la fois à la méthode de décision de l’équipe et à son manque de moyens.
Tant que le risque n’est pas démontré, il n’est pas urgent. Même si personne ne l’admettra, c’est le mantra d’une industrie cyber débordée. Quel RSSI ne connaît pas une vulnérabilité qui paraît plus théorique que pratique, trop coûteuse à traiter, sans propriétaire désigné pour décider et qui dort en conséquence, enfouie dans le suivi des correctifs :
La fondation en tire d’ailleurs une leçon de gouvernance : les décisions se prendront désormais à la majorité plutôt qu’au consensus, le compromis sera encouragé, et les arbitrages qui s’enlisent remonteront beaucoup plus vite jusqu’à sa direction. Reste à savoir si ces promesses résisteront à la prochaine faille de ce calibre et à la vague annoncée de découvertes de vulnérabilités par l’IA.
L’IA fait sauter le verrou de la preuve, pas celui de la décision
L’histoire bascule en 2026, avec l’arrivée des outils d’IA dans la chaîne de sécurité de PHP. Avec le soutien d’Alpha-Omega (le projet de sécurité du logiciel libre lancé en février 2022 sous l’égide de l’Open Source Security Foundation), la fondation a d’abord fait analyser le code par Claude Mythos d’Anthropic, puis a ajouté d’autres outils : Daybreak Red d’OpenAI pour valider les rapports et les exploits, des versions compilées avec des sanitizers (détecteurs d’erreurs mémoire) et des environnements de test répliquant son intégration continue.
Entré dans le programme Patch the Planet d’OpenAI, le projet a ensuite vu la société Calif démarrer un audit le 30 juillet. Douze jours plus tard, le chercheur Ryan A signalait une exécution de code à distance inconditionnelle, de même cause racine que le problème entrevu en 2024. OpenAI a remonté de son côté la même cause, avant que Wiz, le 24 août, puis OpenAI encore, le 18 septembre, ne signalent d’autres vecteurs d’attaque.
Ce que des mois de délibérations internes n’avaient pas su établir, en l’occurrence l’exploitabilité réelle du défaut, la recherche assistée par l’IA l’a donc démontré en quelques jours. À partir du 11 août, sa correction est devenue la priorité absolue de toute l’équipe sécurité de la fondation, mobilisée à plein temps, week-ends et nuits compris, ce qui n’aurait pas été possible, rappelle-t-elle, sans ses propres financements.
La fondation prend toutefois soin de ne pas faire de l’IA un deus ex machina. Le revers de la médaille est un déluge de signalements : depuis le 1er juillet, l’équipe de sécurité a publié 15 CVE et trié plus d’une centaine de rapports invalides, en doublon ou impossibles à reproduire, comme l’a détaillé Alexandre Daubois, qui a rejoint la fondation en juillet pour l’aider à absorber ce flux, dans un billet du 14 octobre. L’IA sert à valider les rapports et à regrouper ceux qui partagent une même cause, mais chaque décision reste celle d’un humain, et chaque correctif est écrit par un humain.
Là réside tout le problème. Les outils d’IA trouvent désormais les failles et comment les exploiter bien plus vite qu’auparavant, que l’on se place du côté des attaquants comme du côté des défenseurs.
Hélas, ces outils ne savent pas encore arbitrer entre compatibilité et performance sur un choix de conception ancré depuis des années dans le moteur. Ce travail exige de rares ingénieurs connaissant tout le code de PHP. Or, constate la fondation, ils sont trop peu nombreux.
Les phases de décision et de réparation sont devenues le nouveau goulet d’étranglement de la cyber.
Fuite, vidéo malencontreuse et embargo rompu
La fondation raconte que la divulgation coordonnée s’est bien passée et est restée sous contrôle jusqu’à deux jours avant la date visée. Mardi 20 octobre, vers 17 h (heure de Paris), les deux identifiants CVE se sont mis à circuler sur des forums et les réseaux sociaux, accompagnés d’une heure de publication erronée et d’un score CVSS de 10,0 au lieu des 9,2 réels. Aucun détail technique n’avait filtré, mais la fondation a dû avancer son pré-avis à 21 h 30 et ramener la publication du jeudi 22 au mercredi 21 octobre, à 16 h. Selon elle, publier sur-le-champ aurait laissé bien des utilisateurs sans moyen simple de se mettre à jour, les distributeurs n’ayant pas fini d’empaqueter le correctif : d’où ce compromis d’un jour d’avance.
Malheureusement, dans la foulée, les maillons de la chaîne ont lâché les uns après les autres. Vers 22 h le mardi, Calif, l’un des chercheurs à l’origine des signalements, a publié par erreur une vidéo montrant sa preuve de concept à l’œuvre sur plusieurs cibles, et dévoilant quelques détails supplémentaires, limités. Supprimée, elle a néanmoins été recopiée sur les réseaux sociaux et a contribué à accélérer la mise au point d’exploits. Les consignes de contournement transmises à quelques fournisseurs d’infrastructures critiques ont, elles aussi, peut-être fuité. Enfin, le mercredi matin à 9 h 41, heure de Paris, soit plus de six heures avant l’heure fixée, Chainguard a publié des images de conteneurs intégrant le correctif. Comme les autres distributeurs, l’éditeur l’avait reçu en avance pour que ses utilisateurs puissent se mettre à jour dès la divulgation. La fondation lui reproche d’avoir rompu l’embargo de sa propre initiative, offrant à n’importe quel attaquant la possibilité d’étudier la correction sous forme binaire pendant que tous les autres attendaient. Chainguard s’en défend ouvertement. Selon Socket, son PDG Dan Lorenc explique avoir pris cette décision en voyant des exploits apparaître un peu partout dans la nature. La fondation, elle, affirme n’avoir identifié aucun exploit fonctionnel au moment de la divulgation. Pourtant, Cloudflare a également observé de premières attaques à peu près au même moment que Chainguard. Difficile de départager les deux camps, mais le différend illustre la fragilité d’une chaîne de divulgation, surtout quand l’IA permet d’élaborer des attaques en quelques minutes.
D’autant que des failles aussi critiques mettent tous les acteurs à cran. Entre les géants du cloud qui doivent déployer des correctifs sur des millions de VM et de conteneurs, les hébergeurs qui veulent protéger leurs clients avant qu’ils ne soient exposés, les éditeurs de sécurité sur les starting-blocks, les réseaux de diffusion, les distributeurs de solutions… la tension est forte et le secret est fragilisé, les cyberattaquants guettant eux-mêmes la moindre publication, ou rumeur de publication, d’un CVE.
Encore un effet de bord de l’IA. Quand Calif et OpenAI, avec des outils de même nature, aboutissent chacun de leur côté à la même cause racine, l’exclusivité de l’information n’existe plus. Avec des modèles open weight de plus en plus agiles et performants en cyber, la situation promet de s’aggraver encore dans les prochaines années, pour ne pas dire dans les prochains mois.
Une alerte organisationnelle
Le billet de la PHP Foundation se referme sur un appel à financement. Entreprises bâties sur PHP, hébergeurs, fournisseurs de cloud, distributions, administrations : tous sont invités à soutenir une fondation dont la sécurité du moteur repose sur une poignée de développeurs rémunérés et un peu de bénévolat, alors que PHP fait tourner services publics, banques, boutiques en ligne et médias. Plaidoyer pro domo, certes. Mais l’audit de 2024, d’où tout est parti, a été payé par un acteur public, et c’est l’argent de la fondation qui a permis, à partir d’août, de mobiliser plusieurs personnes à plein temps.
Voilà pourquoi, à nos yeux, PHP2Shell est bien moins une alerte de sécurité qu’une alerte organisationnelle. Les découvertes de failles par l’IA se multiplient. Du noyau Linux à PHP, de Firefox à Node.js, les CVE critiques s’accumulent depuis la rentrée. Il va falloir revoir notre gestion des risques et des correctifs à grande échelle.
Car à bien y regarder, ces deux failles ne dévoilent pas tant les faiblesses d’un code source que celles d’une gouvernance qui ne tranche pas, d’une expertise trop concentrée, d’un financement sans commune mesure avec la dépendance de toute l’économie à ce logiciel, d’une chaîne de divulgation trop étendue pour conserver un tel secret jusqu’au bout.
L’IA accélère la découverte des failles, mais pas les arbitrages, les budgets ni les renforts nécessaires pour les corriger.
Et les DSI auraient grand tort d’y voir une affaire interne à la communauté open source. Leurs propres organisations vivent exactement la même chose : le correctif repoussé parce que sa correction mécontente trois directions, l’unique expert d’une application qui croule sous les sollicitations, la dépendance à un composant que personne ne finance, la chaîne de partenaires dont un seul suffit à ruiner la discrétion. Sans compter que bien des DSI n’ont pas su dire, le jour J, où PHP s’exécutait dans leur système d’information. Avant d’être un problème de correctifs, PHP2Shell était déjà un problème d’inventaire, donc d’organisation.
Quoi qu’on en dise, les processus de décision grippés et les budgets insuffisants ne portent pas de numéro CVE et ne se corrigent pas d’un patch sorti dans l’urgence. PHP2Shell est une alerte dont on doit collectivement tirer les vraies leçons…
Photo : Boskampi / Pixabay
À LIRE AUSSI :
À LIRE AUSSI :
