La faille PHP attribuée à l'IA avait été aperçue dès 2024
Alors pourquoi personne ne l'avait corrigée ?

Des sites publics éteints par précaution
Le CERT-EU, l'équipe de réponse cyber des institutions européennes, a donné cette semaine une consigne rare : si tu ne peux pas mettre à jour PHP tout de suite, envisage de couper tes applications exposées du réseau public. Un peu comme conseiller à un commerçant de fermer boutique tant que la serrure n'est pas changée. Selon The Register, des services publics finlandais et plusieurs sites néerlandais, dont ceux du Parlement et du régulateur des données, ont été mis hors ligne par précaution.
PHP est le langage qui fait tourner une large part du web. Le 21 octobre, un jour plus tôt que prévu à cause d'une fuite, le projet publie les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux failles critiques, notées 9,2 sur 10, qui permettent dans certaines conditions d'exécuter du code sur un serveur sans s'authentifier. Le projet prévient qu'aucune parade ne remplace la mise à jour.
« L'IA a trouvé la faille »
Le récit est arrivé avec les correctifs. OpenAI range l'affaire parmi les problèmes de sécurité les plus lourds de ces dernières années. Elle l'attribue à la société Calif, qui a trouvé la faille avec GPT-5.6 Sol, le modèle d'OpenAI, dans le cadre de son programme Patch the Planet. À sa connaissance, écrit-elle, l'IA a trouvé ces failles avant les attaquants.
Wiz, qui les a trouvées de son côté, salue la contribution « inestimable » de Gemini 4 Argon, le modèle de Google. Dans le même billet, la responsable de la sécurité de Gemini chez Google DeepMind, Raluca Ada Popa, explique que ces failles sont restées plus de dix ans sans correction parce que les trouver et les exploiter était trop complexe. The Decoder titre que les modèles d'OpenAI et de Google ont trouvé la faille.
Dans ce récit, l'IA est le chien truffier qui déterre ce que personne n'avait flairé. Le même jour, la fondation PHP a publié sa propre version.
Ce que la fondation raconte
En 2024, PHP passe son premier audit de sécurité externe depuis des années. La fondation en a obtenu le financement auprès de la Sovereign Tech Agency, une agence publique allemande. L'audit est organisé par l'OSTIF et mené par la société française Quarkslab.
C'est en corrigeant l'un des problèmes signalés par Quarkslab qu'un développeur du cœur de PHP, sous contrat avec la fondation, repère les premiers signes d'un problème de gestion de la mémoire. Celui-là même qui est à l'origine de la première des deux failles corrigées cette semaine. Une exploitation est alors envisagée en théorie, sans qu'aucun moyen concret d'y parvenir soit trouvé, et d'autres failles à l'impact évident passent devant.
L'équipe de sécurité prépare ensuite plusieurs correctifs concurrents. Chacun a son prix : casser la compatibilité avec le code existant, ouvrir un nouveau risque de déni de service, ou obliger à modifier quantité d'extensions tierces, une coordination qui paraissait impossible. L'équipe décide au consensus, elle craint de livrer le mauvais choix, et les rares développeurs qui connaissent assez le moteur sont accaparés ailleurs. Le chantier cale et redémarre pendant des mois.
On pense à une copropriété qui a plusieurs devis pour une poutre fissurée, aucun sans inconvénient, et qui vote à l'unanimité. La fondation, elle, parle d'un « échec structurel », dû à la fois à la façon dont l'équipe décidait et à son manque de moyens.
Ce que l'IA a changé
Le 30 juillet 2026, Calif commence un audit de PHP. Son chercheur, Ryan Austin, part d'une faille trouvée en 2004 par Stefan Esser, qui était alors la référence de la sécurité de PHP, et demande à l'IA d'en chercher les descendantes encore présentes. Le modèle sert de lampe torche, mais c'est le chercheur qui sait dans quelle cave descendre. Sa conclusion, sur la page de Calif : il faut toujours connaître sa cible, et aucun modèle ne déterre tous les bugs avec une consigne simple.
Le 11 août, Calif signale une exécution de code à distance qui a la même cause racine que le problème vu en 2024. OpenAI signale la même cause, de son côté, le même jour. Wiz suit le 24 août. Calif le reconnaît d'ailleurs dans sa chronologie : un problème apparenté avait été identifié en 2024, sans que son exploitation soit prouvée.
C'est ce qui fait tout basculer. Selon la fondation, ces signalements rendent évident l'impact réel, et la correction devient dès le 11 août la priorité de toute son équipe sécurité, jusqu'à travailler les week-ends. L'IA n'a pas révélé une inconnue. Elle a apporté la démonstration qui manquait pour trancher.
Le patron de Chainguard, Dan Lorenc, a raconté à The Register avoir retrouvé les failles en une soirée, avec un modèle de pointe et une consigne basique. Il venait d'apprendre par un chercheur que quelque chose se préparait dans PHP. Savoir où chercher, encore. Et sur les correctifs, il est formel : il a vraiment fallu des mois pour en bâtir un qui fonctionne.
Trouver n'est plus le problème
Les signalements arrivent désormais plus vite qu'on ne les traite. Depuis le 1er juillet, l'équipe de sécurité de PHP a publié 15 CVE, ces identifiants de failles publiques, et fermé 106 rapports qui n'étaient pas des failles, faisaient doublon ou ne se reproduisaient pas, selon un billet de la fondation du 14 octobre. C'est un service d'urgences où les ambulances arrivent plus vite qu'on ne forme les chirurgiens.
Chez curl, le mainteneur Daniel Stenberg annonce, cité par The Register, que les failles mineures seront désormais traitées en public, faute de temps pour les gérer en privé. PostgreSQL a retiré une dizaine de nouveautés de sa version 19, et l'une des explications avancées est la masse de défauts remontés par la relecture assistée par IA.
La fondation trace une limite nette. Les outils trouvent les bugs. Ils ne savent pas choisir le bon correctif pour un choix de conception ancien du moteur, peser ce qu'il casse, relire le patch. Il faut pour ça des ingénieurs qui connaissent tout le code de PHP, et elle écrit qu'il y en a trop peu.
Depuis le printemps, elle s'organise : une équipe dédiée à la sécurité de l'écosystème en mai, deux recrues en juillet et en septembre, des décisions qui doivent pouvoir se prendre à la majorité. Elle a fait passer PHP au crible de Claude Mythos, d'Anthropic, et valide les rapports avec Daybreak, d'OpenAI. Mais chaque décision et chaque patch restent l'affaire d'un humain.
Un seul financeur public cité
Reste l'argent. PHP fait tourner des services publics, des banques et une bonne partie des logiciels des entreprises. Sa sécurité repose pourtant, selon la fondation, sur un petit groupe de développeurs qu'elle finance et un peu d'aide bénévole. Elle demande aux entreprises, aux hébergeurs et aux États de payer à la hauteur de ce qu'ils en tirent.
Dans tout son billet, un seul financeur public est cité en exemple : l'agence allemande qui a payé l'audit de 2024. La fondation en redemande, et de façon « durable ». C'est pourtant cet audit qui avait mis un développeur sur la piste. Il a fallu deux ans, et une démonstration obtenue avec l'aide de l'IA, pour qu'elle soit suivie jusqu'au bout.
Cet article vous a été utile ?
Sujets abordés :
Questions fréquentes
Quelles failles PHP ont été corrigées le 21 octobre 2026 ?
L'IA a-t-elle découvert la faille de PHP ?
Pourquoi la faille n'a-t-elle pas été corrigée plus tôt ?
Qu'est-ce qui a fait avancer la correction en 2026 ?
Qui a financé l'audit de sécurité de PHP en 2024 ?

Alexandre Noto
Co-fondateur & Expert Tech
Alexandre est dans la tech depuis plus de 20 ans. Entrepreneur, architecte logiciel et passionné d'intelligence artificielle, il traduit les concepts complexes en explications accessibles. Chez Declic Media, il est la voix technique qui rend l'IA compréhensible pour tous.
Tous les articles de Alexandre →