Article de Julien Ricciarelli-Bonnal
24 octobre 2026
L’essentiel
Le 21 octobre 2026, les responsables du langage PHP ont publié des correctifs d’urgence pour deux vulnérabilités critiques, identifiées avec l’aide de chercheurs utilisant notamment des modèles d’intelligence artificielle. Ces failles, regroupées sous le nom de PHP2Shell, peuvent permettre l’exécution de code à distance sur certains serveurs vulnérables. L’affaire concerne un langage présent sur environ 70 % des sites internet et a provoqué une mobilisation internationale, accompagnée de mises hors ligne préventives. Au-delà de l’incident, elle révèle une transformation de la cybersécurité : l’IA accélère la recherche de failles, mais les organisations doivent encore trouver les moyens humains et techniques de les corriger avant leur exploitation.
Pendant des années, la recherche de vulnérabilités informatiques a reposé sur une combinaison d’expertise humaine, d’outils automatisés et d’analyses approfondies du code. Les chercheurs identifiaient des comportements anormaux, étudiaient les interactions entre composants logiciels et tentaient de démontrer qu’une faiblesse pouvait être exploitée. Ce travail pouvait nécessiter plusieurs semaines, parfois plusieurs mois, surtout lorsqu’il concernait les mécanismes internes d’un langage de programmation.
Le 21 octobre 2026, l’annonce de deux failles critiques dans PHP a donné une dimension particulièrement concrète à l’arrivée de l’intelligence artificielle dans cette activité. Des équipes de recherche ont utilisé des modèles avancés pour explorer des problèmes techniques complexes, tandis que les responsables du langage et plusieurs fournisseurs de sécurité coordonnaient la publication des correctifs. L’alerte a concerné une technologie utilisée par une très grande partie du Web.
La découverte ne signifie pas que l’ensemble des sites utilisant PHP était immédiatement piratable. Elle pose néanmoins une question beaucoup plus large : si les systèmes d’intelligence artificielle permettent de découvrir plus rapidement des vulnérabilités majeures, les défenseurs disposeront-ils d’une capacité équivalente pour les analyser, les corriger et déployer les mises à jour avant les attaquants ?
Deux failles au cœur du fonctionnement de PHP
PHP est un langage de programmation exécuté côté serveur, utilisé notamment dans des systèmes de gestion de contenu, des applications commerciales et de nombreux services web. Selon les estimations citées lors de cette crise, il intervient dans le fonctionnement d’environ 70 % des sites internet. Cette proportion mesure la diffusion d’une technologie, non le nombre de serveurs effectivement vulnérables aux deux failles découvertes.
Les vulnérabilités CVE-2026-109618 et CVE-2026-109619, toutes deux évaluées à 9,2 sur l’échelle CVSS 4.0, concernent des mécanismes internes de gestion de la mémoire et de traitement des erreurs. La première peut, dans certaines circonstances, provoquer une corruption de mémoire lorsqu’une requête atteint une limite de ressources à un moment particulier. La seconde concerne la conservation d’un état interne devenu invalide après certaines erreurs fatales, pouvant conduire à réutiliser une zone mémoire libérée.
Ces descriptions paraissent éloignées des préoccupations habituelles d’un exploitant de site internet. Leur conséquence potentielle est pourtant majeure : dans des configurations vulnérables et sous certaines conditions, un attaquant non authentifié peut parvenir à exécuter du code sur le serveur. Il ne s’agit plus simplement de perturber l’affichage d’une page, mais de compromettre éventuellement des traitements, des fichiers ou des données accessibles au processus concerné.
La Fondation PHP a publié quatre versions corrigées le 21 octobre : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. La correction était d’autant plus délicate que les composants touchés se situent au cœur du langage. Modifier leur comportement sans compromettre la compatibilité des applications, des extensions et des environnements existants constitue une opération sensiblement plus complexe que corriger une fonctionnalité isolée.
L’intelligence artificielle accélère une recherche qui reste humaine
L’implication d’OpenAI a largement contribué à la médiatisation de l’affaire. Dans le cadre de son initiative Patch the Planet, l’entreprise indique que la société de cybersécurité Calif a identifié une faille critique à l’aide de GPT-5.6 Sol. La société Wiz a, de son côté, découvert et signalé indépendamment les deux vulnérabilités, en mobilisant également différents outils d’intelligence artificielle dans ses recherches.
Il serait pourtant inexact de présenter ces failles comme des problèmes que personne n’avait jamais entrevus avant l’arrivée de l’IA. La Fondation PHP explique que les premiers signes du défaut à l’origine de la première vulnérabilité avaient été identifiés dès 2024, à la suite d’un audit de sécurité. À cette époque, les équipes n’avaient pas établi de scénario concret d’exploitation suffisamment convaincant et la recherche d’une correction s’était enlisée dans plusieurs difficultés techniques et organisationnelles.
L’apport décisif des recherches menées en 2026 a notamment consisté à transformer une faiblesse difficile à caractériser en risque démontré. Les modèles avancés peuvent aider à explorer des interactions entre composants, tester des hypothèses et identifier des séquences d’exécution inhabituelles. Ils permettent d’accélérer certaines étapes qui reposaient auparavant sur une exploration manuelle particulièrement exigeante.
Mais la découverte d’un comportement exploitable ne produit pas automatiquement un correctif fiable. Les mainteneurs doivent reproduire le problème, évaluer ses conséquences, concevoir une modification compatible avec les applications existantes et vérifier qu’elle n’introduit pas d’autres défaillances. La Fondation PHP insiste d’ailleurs sur la place maintenue des décisions humaines dans le traitement des signalements. L’IA augmente les capacités de recherche ; elle ne supprime ni l’expertise nécessaire ni la responsabilité de ceux qui entretiennent le logiciel.
Entre la découverte et le correctif, une fenêtre de sécurité fragile
La divulgation des vulnérabilités est devenue un sujet presque aussi important que leur découverte. Pendant plusieurs semaines, chercheurs, responsables de PHP, fournisseurs d’infrastructure et acteurs de la cybersécurité ont préparé les correctifs et les protections destinées aux organisations concernées. OpenAI présente cette coordination comme une fenêtre d’avance accordée aux défenseurs avant la diffusion publique des informations techniques.
Cette fenêtre s’est révélée fragile. Le 20 octobre, des identifiants de vulnérabilités ont commencé à circuler prématurément, accompagnés d’informations inexactes. Une vidéo montrant une preuve de concept a également été publiée par erreur. Les responsables du langage ont avancé la sortie des correctifs, initialement prévue le 22 octobre, au 21 octobre. La Fondation PHP a aussi signalé une publication anticipée de composants corrigés par un distributeur, susceptible de fournir des indices aux personnes cherchant à reconstituer les défauts.
La publication d’un correctif rend en effet possible une opération classique en cybersécurité : comparer le code vulnérable et le code réparé afin d’identifier ce qui a changé. Cette analyse peut aider les administrateurs à comprendre la faille, mais également les attaquants à développer des moyens d’exploitation contre les installations non mises à jour. L’intelligence artificielle peut accélérer ce travail des deux côtés.
Les observations disponibles jusqu’au 23 octobre imposent néanmoins de distinguer les tentatives d’attaque des compromissions réussies. Plusieurs acteurs ont signalé des activités de reconnaissance, des essais d’exploitation et la circulation de preuves de concept. CrowdStrike indiquait toutefois ne pas avoir observé d’exploitation réussie dans ses environnements de surveillance et soulignait la difficulté technique de transformer certains essais en attaques fiables. Le risque est sérieux, sans que toutes les prévisions les plus alarmantes puissent être considérées comme réalisées.
La véritable difficulté consiste à corriger des millions de systèmes différents
L’ampleur de l’utilisation de PHP explique la mobilisation des autorités de cybersécurité et des opérateurs. Plusieurs administrations et organisations ont temporairement interrompu certains services pendant la phase de sécurisation. Ces indisponibilités ne signifiaient pas nécessairement qu’une attaque avait réussi : dans plusieurs cas, il s’agissait de mesures de précaution prises pendant la vérification des installations et le déploiement des mises à jour.
Une vulnérabilité affectant un composant largement diffusé ne produit pas les mêmes conséquences selon les environnements. La version installée, le serveur web, les extensions utilisées et les chemins d’exécution accessibles jouent un rôle déterminant. Un site fonctionnant sous PHP n’est donc pas automatiquement exposé de la même manière qu’un autre, même lorsque tous deux reposent sur le même langage.
Pour les entreprises, la difficulté peut commencer avant toute opération technique. Elles savent généralement quel outil de gestion commerciale ou quelle plateforme de commerce électronique elles utilisent, mais pas toujours quelle version de PHP fonctionne derrière chaque application. Un ancien extranet, un module développé sur mesure ou un service exploité par un prestataire peuvent rester absents de l’inventaire quotidien du système d’information.
C’est pourquoi la réponse ne peut se réduire à une recommandation générale de mise à jour. Elle exige d’identifier les instances concernées, de vérifier leurs versions, de déterminer les dépendances et de coordonner les interventions avec les hébergeurs ou fournisseurs. Les protections provisoires, notamment les règles de pare-feu applicatif, peuvent réduire certaines expositions sans remplacer définitivement les correctifs du logiciel.
Les organisations confrontées à cette situation découvrent parfois un problème de gouvernance plus ancien que l’incident lui-même : elles disposent d’une infrastructure opérationnelle sans avoir une visibilité complète sur les composants qui la constituent. La question rejoint, dans un autre contexte, celle que nous avions examinée à propos des agents d’OpenAI dont les actions devenaient difficiles à retracer. Plus les systèmes deviennent complexes, plus l’identification des responsabilités et la capacité de contrôle prennent de l’importance.
Une cybersécurité plus rapide dépendra aussi des moyens consacrés à la maintenance
L’affaire PHP révèle enfin une contradiction économique rarement visible pour les utilisateurs d’Internet. Des infrastructures utilisées par des millions d’entreprises et d’organisations reposent en partie sur des projets open source dont les équipes de maintenance disposent de moyens limités. Leur importance économique réelle peut être considérablement supérieure aux ressources mobilisées pour assurer leur sécurité.
La Fondation PHP a reconnu que le traitement de l’une des failles s’était enlisé pendant plusieurs mois, en raison de difficultés de décision et d’un manque de personnes possédant une connaissance suffisamment approfondie du moteur. Elle a engagé des changements d’organisation pour améliorer le traitement des alertes. Parallèlement, l’arrivée d’outils d’intelligence artificielle augmente le volume des signalements, y compris ceux qui s’avèrent inexacts, redondants ou impossibles à reproduire.
Cette évolution pourrait créer un déséquilibre nouveau. Si l’IA permet de découvrir davantage de vulnérabilités, les équipes chargées de les corriger devront absorber une quantité croissante d’informations, vérifier les preuves, arbitrer les modifications et accompagner leurs utilisateurs. Une capacité de détection multipliée sans renforcement comparable de la maintenance ne garantit pas une amélioration proportionnelle de la sécurité.
Pour les entreprises, cette transformation rappelle que la cybersécurité ne dépend pas seulement du choix d’une technologie performante. Elle suppose des responsabilités identifiées, des processus de décision, des compétences disponibles et une capacité réelle d’exécution. Cette logique de structuration rejoint plus largement les principes d’une gouvernance de l’IA en entreprise, qui doit distinguer les possibilités offertes par les outils des conditions nécessaires à leur utilisation maîtrisée.
L’initiative Patch the Planet cherche précisément à organiser une réponse collective entre chercheurs, mainteneurs, fournisseurs de sécurité et institutions. Son intérêt dépasse la contribution d’un modèle particulier : elle reconnaît qu’une découverte techniquement impressionnante ne protège personne tant que des correctifs fiables ne sont pas développés, distribués et effectivement installés.
Le véritable changement introduit par l’intelligence artificielle pourrait donc concerner moins la découverte de failles en elle-même que la vitesse à laquelle elles deviennent démontrables. Les vulnérabilités peuvent rester présentes pendant des années dans des logiciels largement utilisés ; ce qui évolue, c’est la capacité à en révéler plus rapidement le potentiel d’exploitation.
L’épisode PHP2Shell ne démontre ni que l’IA rendra Internet automatiquement plus sûr ni qu’elle donnera nécessairement l’avantage aux cybercriminels. Il montre que les deux camps disposent progressivement de moyens d’analyse plus puissants, tandis que les délais de correction, eux, restent contraints par la complexité des logiciels et les ressources humaines disponibles. Dans cette nouvelle course, découvrir une faille avant les attaquants constitue un avantage. Parvenir à protéger effectivement les systèmes concernés avant qu’ils ne soient compromis restera la véritable mesure de cet avantage.
Rédigé par Julien Ricciarelli-Bonnal
24 octobre 2026
