Une cause connue depuis 2024 Les deux failles critiques de PHP, corrigées le 21 octobre et notées 9,2 sur 10, ont une histoire particulière. Leur cause avait été repérée dès 2024 par un développeur du cœur de PHP, lors de la correction d'un problème signalé par un audit. Personne n'avait alors démontré qu'elle était exploitable. Les discussions sur le correctif se sont enlisées. La fondation PHP parle elle-même d'un échec structurel. L'IA change la donne Le 11 août 2026, une équipe de chercheurs travaillant dans le cadre d'un programme d'OpenAI signale, avec l'aide d'un modèle de pointe, une possibilité d'exécution de code à distance liée à cette même cause. OpenAI indique l'avoir identifiée de son côté le même jour. Quelques jours plus tard, des chercheurs de Wiz démontrent, avec plusieurs modèles, des attaques sans authentification contre des installations WordPress et Drupal. Leur constat : un seul chercheur a accompli en une semaine un travail qui aurait mobilisé une équipe pendant plusieurs mois. Les versions touchées remontent à PHP 5.4. Plus de dix ans de code. Dans la même période, curl a corrigé une faille HTTP/2 repérée avec l'aide d'un assistant d'IA. Le phénomène ne se limite pas à PHP. Des vulnérabilités qui redeviennent rentables Le premier effet est mécanique. Des failles anciennes, laissées dormantes parce que trop coûteuses à exploiter, redeviennent exploitables. Ce qui demandait des mois d'expertise se fait en jours. Le second concerne les délais. Entre découverte et exploitation, l'écart se réduit. Dans le cas de PHP, des détails ont fuité avant la publication du correctif, qui a dû être avancée de 24 heures. Un avantage pour qui s'en sert en premier Il serait faux de conclure que l'IA favorise les attaquants. Les mêmes outils servent aux défenseurs. C'est d'ailleurs l'IA qui a permis de trouver puis de corriger ces failles. Mais l'avantage revient à celui qui l'intègre le premier dans un processus régulier. Intégrer l'IA dans les tests de sécurité Pour une équipe de développement, la question devient très concrète. Les tests de sécurité se limitent-ils à un scan automatisé en fin de cycle et à un audit annuel ? Ou intègrent-ils déjà une analyse assistée par IA, sur chaque modification des composants exposés, et une revue des dépendances les plus anciennes ? Car d'autres feront ce travail sur votre code. Autant le faire avant eux.
