Failles trouvées par IA : le cadre de divulgation qu'OpenAI propose après PHP2Shell

Le 21 octobre 2026, l'équipe PHP a publié les correctifs de CVE-2026-109618 et CVE-2026-109619, deux failles du moteur qui permettaient d'exécuter du code à distance sans authentification. Le même jour, OpenAI a raconté sur son blog les deux mois de coordination qui avaient précédé, et en a tiré un cadre en cinq étapes pour répondre aux failles critiques que l'IA trouve dans des logiciels très répandus. L'entreprise demande à la communauté sécurité de l'amender¹.

Le récit de la faille elle-même (versions touchées, chronologie, mitigations) est dans notre article PHP2Shell du 21 octobre. Cette page porte sur la méthode.

Qui a fait quoi pendant deux mois

OpenAI décrit une coalition qu'elle dit avoir menée. La firme Calif a trouvé une faille critique avec GPT-5.6 Sol, dans le cadre du programme Patch the Planet ; Wiz a découvert et signalé les deux vulnérabilités de son côté. Les mainteneurs de PHP ont écrit les correctifs et décidé de la publication ; OpenAI, Wiz, Cloudflare et d'autres ont fourni recherche, support technique et coordination pour préparer les protections avant la divulgation¹. Selon la chronologie de Sansec, Calif avait repéré des chemins d'exécution de code dès le 1er août et signalé une première faille le 11 août⁷ ; Wiz indique avoir trouvé les failles le 19 août avec son agent Atlas, Gemini 4 Argon et GPT-5.6 Sol, et les avoir signalées le 24². La paternité de la découverte reste partagée.

OpenAI écrit qu'à sa connaissance, l'IA de frontière a trouvé ces failles avant les attaquants, et nomme « Defender's Window » le délai ainsi gagné par les mainteneurs et les fournisseurs de sécurité¹. L'entreprise ajoute que ces bugs font partie de plusieurs vulnérabilités importantes déjà trouvées et en cours de correction, et qu'elle s'attend à une forte hausse de découvertes comparables dans les mois qui viennent.

Les cinq étapes

Pour une faille qui touche beaucoup de produits, ou qui demande du temps aux distributeurs et aux hébergeurs, OpenAI propose de dérouler la réponse en cinq temps¹ :

1. Valider et corriger en amont. Le mainteneur, les chercheurs et quelques partenaires techniques confirment la faille, mesurent son impact, écrivent et testent le correctif. Des modèles de frontière attaquent le correctif lui-même pour chercher un contournement ou une variante de la faille.
2. Laisser du temps aux organisations touchées. Un distributeur adapte le correctif à une ancienne version, un hébergeur teste une mitigation, un fournisseur de sécurité prépare des règles de détection ou de WAF. Les mainteneurs décident qui est mis dans la confidence.
3. Coordonner avec les acteurs publics. Pour PHP, OpenAI et ses partenaires ont travaillé avec la Super Intelligence Force de la Maison-Blanche, l'Office of the National Cyber Director (ONCD), la CISA et des partenaires internationaux, pour que les consignes atteignent les opérateurs d'infrastructures critiques.
4. Préparer les mises à jour dans les produits touchés. Une fois le correctif et le plan de divulgation stabilisés, le cercle s'élargit à d'autres distributeurs, hébergeurs, équipes de réponse et exploitants.
5. Publier les consignes et accompagner le déploiement. Le site Patch the Planet rassemble les avis publics, renvoie aux correctifs officiels et aux recherches des partenaires, et décrit les mitigations provisoires avec leurs limites.

Deux règles encadrent les étapes. Le choix des organisations prévenues repose sur trois critères : leur rôle de protection (de leurs propres systèmes et de leurs clients), le temps dont elles ont besoin pour agir, leur capacité à garder une information sensible ; les mêmes critères s'appliquent aux organisations comparables. L'information est graduée : un participant reçoit ce qu'il lui faut pour son travail de protection, des journaux réseau avec indicateurs de compromission jusqu'aux preuves de concept d'exploit les plus sensibles. Le calendrier se réévalue en cas d'exploitation active, de fuite, de correctif public trop parlant ou de remédiation qui piétine¹.

Ce que le cadre ajoute à la divulgation coordonnée

La divulgation coordonnée classique, décrite par les normes ISO/IEC 29147 et 30111, met face à face un découvreur et un éditeur, parfois avec un coordinateur. Google Project Zero en a fixé la référence de délai : 90 jours pour corriger, puis 30 jours d'adoption avant la publication des détails³. Le cadre d'OpenAI garde l'embargo et donne la main aux mainteneurs, mais il ajoute trois choses : des modèles qui attaquent le correctif avant sa sortie, un cercle de destinataires élargi par vagues selon des critères écrits, et l'État dans la boucle dès l'embargo.

OpenAI note une contrainte que la pratique de 90 jours n'avait pas : le temps laissé aux distributeurs risque de manquer si les capacités de frontière ne sont pas très en avance sur celles qui circulent largement¹. PHP2Shell l'a montré. Les identifiants CVE ont fuité le 20 octobre, et PHP a publié un préavis le soir même pour une sortie le lendemain à 14 heures UTC, en se réservant le droit d'avancer la date⁴. Un secret partagé pendant deux mois entre mainteneurs, chercheurs, fournisseurs de sécurité et agences publiques a tenu jusqu'aux dernières 48 heures.

Pour une organisation européenne, le cadre s'ajoute à une obligation légale. Depuis le 11 septembre 2026, l'article 14 du Cyber Resilience Act impose aux fabricants de notifier toute vulnérabilité activement exploitée dans leurs produits, avec une alerte précoce sous 24 heures, via la plateforme unique de l'ENISA⁵. Le billet d'OpenAI cite des agences américaines et des partenaires internationaux, sans nommer l'ENISA ni les CSIRT nationaux comme le CERT-FR.

Les questions qu'OpenAI laisse ouvertes

OpenAI ouvre un formulaire de retour et liste quatre points sur lesquels elle attend la communauté¹ :

• La durée des fenêtres. Combien de temps faut-il aux mainteneurs et aux exploitants pour préparer et déployer un correctif fiable, et quels signaux doivent avancer la divulgation ?
• Le patch d'urgence. Un gouvernement ou un opérateur peut-il exploiter une faille pour corriger des systèmes qu'il possède ou qu'il est autorisé à gérer, après en avoir perdu l'accès administrateur ? OpenAI évoque même un balayage permanent de l'internet qui préviendrait les propriétaires d'un site vulnérable, ou corrigerait le système.
• La notification préalable. Qui doit être prévenu, y compris des défenseurs qu'on risque d'oublier, et comment arbitrer entre couverture et risque de fuite ?
• Les paquets sûrs par défaut. Comment corriger les paquets en aval pendant que le correctif amont se prépare, ou rétroporter un correctif vers des versions qui ne reçoivent plus de mises à jour ?

La deuxième question est la plus lourde pour une DSI : elle envisage qu'un tiers, même autorisé, corrige un système en passant par la faille qu'il veut fermer. Votre politique de sécurité doit dire qui a le droit de toucher à vos serveurs, et dans quelles conditions, avant que la question ne se pose dans l'urgence.

OpenAI accompagne le cadre de deux outils : un vérificateur de version PHP, publié en dépôt GitHub sous forme de script en ligne de commande et de deux compétences Codex (l'une interroge les en-têtes HTTP d'un site, l'autre la version installée sur un serveur)¹⁶, et un engagement d'un milliard de dollars d'accès subventionné à Daybreak, sa suite de cyberdéfense, via le programme Daybreak for Frontline Defenders, destiné aux organisations aux ressources de sécurité limitées qui protègent des services essentiels¹.

Ce que les DSI peuvent en tirer

Connaître son inventaire avant la prochaine alerte. Savoir où tourne PHP chez vous, et dans quelle version, doit prendre quelques minutes, images de conteneurs et hébergements mutualisés compris. Le cadre d'OpenAI organise ce qui précède la divulgation ; une organisation qui n'est pas dans le cercle découvre la faille le jour de la publication, comme tout le monde.

Réduire le délai entre correctif et production. Après la publication, tout dépend de votre vitesse à tester et à déployer. Une chaîne CI/CD qui reconstruit et redéploie toutes les applications d'une stack en une journée vous protège mieux qu'une place dans la liste des pré-notifiés.

Traiter les dépendances comme du code à soi. PHP2Shell vivait dans un composant que la plupart des équipes ne lisent jamais. Les modèles qui ont trouvé ces failles lisent aussi le code applicatif qui repose dessus. Bank of America a chiffré ce que coûte la correction à grande échelle : 1 000 prestataires en renfort de 3 000 salariés.

Encadrer les agents qui vérifient et corrigent. Utilisé avec sa compétence serveur, le vérificateur d'OpenAI fait inspecter vos machines par un agent pour relever des versions. Faites-le tourner dans un périmètre limité, en lecture seule, sans accès au reste du système d'information (voir pourquoi un agent d'analyse n'est pas un bac à sable).

Répondre à l'appel d'OpenAI, ou à celui de l'ENISA. Le cadre est en consultation. Une DSI européenne qui opère des services essentiels a des choses à dire sur la notification préalable et sur le patch d'urgence par un tiers, et le CERT-FR reste son coordinateur pour les signalements.

Sources

1. OpenAI, « Patch the Planet: global response coordination as agents uncover critical vulnerabilities » (coalition de deux mois, Calif et GPT-5.6 Sol, Wiz, rôle des mainteneurs, Defender's Window, cinq étapes, critères de notification, information graduée, réévaluation du calendrier, Super Intelligence Force, ONCD, CISA, temps disponible, questions ouvertes et formulaire, vérificateur en compétence Codex, Daybreak for Frontline Defenders) — openai.com, 21 octobre 2026.
2. Wiz Research, « PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet » (découverte du 19 août avec Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol, signalement du 24 août) — wiz.io, 21 octobre 2026.
3. Google Project Zero, Tim Willis, « Policy and Disclosure: 2025 Edition » (délai de 90 jours, politique 90+30) — projectzero.google, 29 juillet 2025.
4. PHP Foundation, préavis publié sur son Discourse (sortie le 21 octobre à 14 heures UTC, clause d'avancement en cas de fuite ou d'exploitation) — discourse.thephp.foundation, 20 octobre 2026 ; Tenable, « php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ » (circulation des identifiants CVE le 20 octobre) — tenable.com.
5. ENISA, « The CRA Single Reporting Platform is launched » (mise en service le 11 septembre 2026) — enisa.europa.eu ; règlement (UE) 2024/2847, article 14 — eur-lex.europa.eu.
6. OpenAI, dépôt php2shell-checker — github.com, créé le 21 octobre 2026 (script phpcheck.js, compétences phpcheck-url et phpcheck-server).
7. Sansec, « PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619) » (chronologie : Calif le 1er et le 11 août) — sansec.io, 21 octobre 2026.