OpenAI a trouvé les failles de PHP. Les deux mois d'après comptent davantage.

PHP fait tourner à peu près soixante-dix pour cent du web. Ce mois-ci, OpenAI a annoncé que ses modèles, dont GPT-5.6 Sol, avaient aidé des chercheurs à y trouver des failles de sécurité critiques. Cette phrase, c'est le titre. La suivante, c'est l'histoire : l'entreprise a ensuite passé deux mois au sein d'une coalition de mainteneurs et de prestataires de sécurité à développer et tester des correctifs avant que quoi que ce soit ne devienne public.

Deux mois de silence, ce n'est pas un cycle de communication. C'est la partie du travail sur les vulnérabilités que personne ne peut mettre en capture d'écran.

La divulgation coordonnée, c'est le produit

Trouver des bugs avec un modèle ne coûte plus rien. Un bon agent, un shell, une copie du code source et quelques heures, et il sort des crashs candidats plus vite qu'un relecteur humain sur le même code. La plupart seront des déchets, et c'est justement le tri entre déchet et vrai problème de sûreté mémoire qui a déplacé le coût.

Ce qu'OpenAI a fait ici, ou du moins ce qu'elle affirme avoir fait, c'est le milieu ingrat : monter une coalition, vérifier chaque candidat, écrire des patchs, les tester contre l'écosystème, convenir d'une date de divulgation, et seulement ensuite publier. C'est cette séquence qui a évité qu'une faille PHP devienne un week-end d'exploitations contre des sites WordPress.

Ce qui veut dire que la vraie question n'est pas de savoir si un modèle a trouvé quelque chose. C'est de savoir si ce dispositif peut se répéter. Une coalition fonctionne quand un acteur bien doté la convoque. Ça ne s'étend pas évidemment aux milliers de projets open source qui pendent au même graphe de dépendances que PHP et n'ont personne pour convoquer quoi que ce soit.

{{INLINE1}}

Le vérificateur est honnête sur ce qu'il ne sait pas faire

En même temps que la divulgation, OpenAI a publié un vérificateur de version PHP : un skill Codex et un outil en ligne de commande Node. On le pointe vers un site, il lit les en-têtes HTTP, puis répond OK, VULNERABLE ou UNKNOWN.

La méthode mérite qu'on s'y arrête. Elle compare la chaîne de version de l'en-tête à des seuils de correctif connus. Elle ne vérifie rien par elle-même. C'est un choix de conception assumé, et il produit un outil à trois sorties honnêtes plutôt qu'à deux sorties malhonnêtes.

La détection par en-tête a un mode de défaillance connu : beaucoup de déploiements PHP de production mentent sur leur version, soit parce qu'un reverse proxy réécrit l'en-tête, soit parce qu'il est supprimé, soit parce que quelqu'un a désactivé expose_php il y a des années et que plus personne ne s'en souvient. C'est à ça que sert UNKNOWN. Un outil qui dit « je ne peux pas savoir » est plus utile qu'un outil qui dit « tout va bien ».

Le canal de distribution est l'autre détail intéressant. C'est sorti comme skill Codex, pas comme application web ni comme GitHub Action. C'est une déclaration sur l'endroit où OpenAI pense que le triage sécurité va se jouer : à l'intérieur de l'agent qui lit déjà votre dépôt.

Comment un modèle trouve un bug mémoire

Il vaut la peine d'être précis sur le mécanisme, parce que « l'IA a trouvé des vulnérabilités » sert à désigner trois choses différentes.

La première, c'est du fuzzing avec un ordonnanceur plus intelligent. Les fuzzers guidés par la couverture trouvent des bugs PHP depuis dix ans ; ce qu'un modèle ajoute, c'est la capacité de lire un patch, de deviner quel chemin de code voisin devient atteignable, et d'écrire le harnais qui l'exerce. C'est réellement utile et parfaitement dénué de magie.

La deuxième, c'est le raisonnement sur le code. Face à une fonction qui lit un préfixe de longueur puis alloue, un modèle solide signalera le dépassement d'entier et proposera une entrée candidate, sans rien exécuter. C'est de là que viennent la plupart des faux positifs, parce que le modèle ne voit pas l'appelant trois fichiers plus loin qui borne déjà la valeur.

La troisième, c'est le triage. Ranger quelques centaines de candidats entre « probablement réel », « probablement du bruit » et « il faut un humain », c'est l'usage le moins commenté et sans doute le plus rentable, parce que c'est l'étape qui décide si une équipe sécurité a le temps de regarder quoi que ce soit.

Seule la troisième passe à l'échelle sans coalition. Et c'est le problème discret de toute cette annonce : le travail sur le modèle est reproductible par quiconque a une clé API, le travail de coordination, non.

Un milliard de dollars d'accès

OpenAI a aussi engagé un milliard de dollars d'accès à Daybreak pour les défenseurs en première ligne. À lire comme de l'infrastructure, pas comme de la charité. Un outil de détection n'aide que si ceux qui le font tourner peuvent se le permettre au rythme où arrivent les attaques. Un palier gratuit permet à l'équipe IT d'un hôpital de vérifier une fois. Un milliard de calcul engagé lui permet de vérifier en continu.

Il y a dessous une logique stratégique qu'il vaut la peine de nommer. Si les fournisseurs de modèles deviennent l'amont de l'outillage sécurité, ils deviennent aussi celui qui décide quelles vulnérabilités sont trouvées d'abord, et à qui on les annonce. Ça fait beaucoup de jugement concentré dans un laboratoire commercial, et le processus de divulgation décrit plus haut est exactement ce qui détermine si ce dispositif est digne de confiance.

C'est aussi un argument de recrutement. Les chercheurs en sécurité sont rares, et un laboratoire qui peut montrer deux mois de correctif coordonné sur le langage le plus répandu du web a une meilleure histoire à raconter qu'un labo qui publie un benchmark.

Ce que ça veut dire si vous gérez un site

Vérifiez votre version de PHP cette semaine, et vérifiez-la depuis l'extérieur de votre réseau, puisque c'est ce que voit un attaquant. Si l'en-tête ne vous dit rien, il vous reste un travail qu'aucun scanner ne fera à votre place, parce que la seule réponse fiable vit dans le gestionnaire de paquets de la machine.

Ensuite, pensez au motif plutôt qu'à l'incident. Le modèle n'a pas remplacé l'équipe sécurité. Il a changé le ratio : plus de candidats, plus de triage, autant de gens qualifiés pour trancher. Chaque organisation qui adopte ces outils devra construire une capacité de triage quelque part, et celles qui ne le feront pas finiront avec un stock de constats non lus qui ressemble exactement à un scan jamais lancé.

La partie qu'on oubliera

Encore un détail à noter : l'outil livré est un vérificateur de version, pas un patcheur. Personne n'a donné aux propriétaires de sites un correctif en un clic, parce qu'un correctif en un clic déployé sur soixante-dix pour cent du web, c'est une panne en soi. Le choix conservateur est le bon, et c'est aussi celui qui garantit une longue traîne d'installations non corrigées, d'où viendra le prochain incident.

Dans six mois, la leçon retenue sera « l'IA a trouvé des bugs PHP », qui est la phrase vraie la moins intéressante disponible. L'enseignement transposable est plus terne : la valeur était dans ces deux mois de travail coordonné, et la contribution du modèle a été d'accélérer la première semaine de ce processus.

Ça reste énorme. Ce n'est juste pas ce que vend l'annonce. Le travail de sécurité a toujours été surtout de la coordination, et les outils qui aident le plus sont ceux qui rendent la coordination moins chère, pas ceux qui rendent la découverte plus bruyante.