Une faille détectée n’est pas encore une attaque réussie, comment les agents de GPT-6 Cyber passent de la piste au correctif

La chaîne d’agents de GPT-6 Cyber confronte les failles suspectées à des tests isolés, puis cherche à démontrer leur exploitation avant de proposer une réparation. Ce parcours comporte plusieurs filtres, mais exige aussi de vérifier ce que les tests ont réellement prouvé.

Par Antoine Lemaire · 07/11/2026 à 05h06

Le repérage produit des pistes, pas des preuves

GPT-6 Cyber est présenté par OpenAI comme un modèle spécialisé capable de rechercher des vulnérabilités, d’en éprouver l’exploitation et de suggérer une réparation. Pour comprendre son fonctionnement, il faut séparer ces tâches. Repérer un morceau de code suspect ne démontre ni qu’un défaut peut être reproduit, ni qu’un attaquant peut en tirer un avantage.

La campagne menée sur Linux illustre ce premier tri. OpenAI dit avoir limité l’analyse à environ 7 % du noyau, en ciblant du code accessible à un utilisateur dépourvu de privilèges. Les agents ont relevé 2 308 pistes. Ce nombre décrit donc des hypothèses à examiner, et non autant d’attaques réussies.

Cette recherche ne doit pas être confondue avec la surveillance matérielle, comme la mesure de température avec Core Temp, ou avec les tests de stabilité IntelBurnTest. Ici, l’objectif est d’établir si une faiblesse logicielle permet une action qui devrait être interdite, puis d’en apporter la preuve.

La machine virtuelle sert à éprouver chaque hypothèse

Les pistes passent ensuite par des essais dans une machine virtuelle isolée. Ce dispositif permet d’exécuter les tests dans un environnement séparé. À l’issue de cette phase, OpenAI annonce 1 724 failles reproductibles. La différence avec le repérage initial montre pourquoi une alerte ne suffit pas : toutes les pistes ne franchissent pas l’épreuve de la reproduction.

L’étape suivante consiste à produire un exploit, c’est-à-dire un programme qui utilise la vulnérabilité pour obtenir un effet interdit. Pour cette campagne, OpenAI rapporte 1 169 programmes d’attaque fonctionnels avant le retrait des doublons, puis 948 vulnérabilités exploitables. Compter les programmes et compter les failles ne revient donc pas au même : plusieurs résultats peuvent correspondre à une même vulnérabilité.

L’effet recherché était ici une élévation de privilèges : un utilisateur local sans droits particuliers obtenait les droits root, les plus étendus sur le système. Cela suppose déjà de pouvoir y exécuter du code. Ces failles ne constituent pas, à elles seules, une porte d’entrée à distance. La démonstration doit donc être lue avec ses conditions de départ, et non comme une capacité à compromettre n’importe quelle machine.

Une attaque réussie peut prouver la mauvaise faille

Même un résultat spectaculaire peut être trompeur. Lors d’un premier essai, 20 programmes parmi 200 exploits comptabilisés comme réussis avaient obtenu les droits root en passant par une vulnérabilité différente de celle qu’ils étaient censés tester. Le résultat final était bien atteint, mais l’explication de sa réussite était erronée.

Cette limite impose de distinguer deux vérifications : constater l’effet de l’attaque et identifier le défaut qui l’a rendu possible. Sans ce second contrôle, une proposition de réparation risque de viser une faiblesse qui n’explique pas le résultat observé. L’automatisation des essais ne dispense donc pas de vérifier le lien entre la faille annoncée et l’exploitation démontrée.

La chaîne se poursuit avec la transmission aux mainteneurs. OpenAI indique avoir envoyé 304 failles critiques de Linux accompagnées de propositions de correctifs. Une proposition n’est pas un correctif accepté. L’examen par les responsables du logiciel reste une étape distincte : produire une modification et la faire intégrer ne sont pas deux façons de désigner la même opération.

Les garde-fous encadrent aussi les actions des agents

Le périmètre autorisé constitue une autre limite à contrôler. OpenAI annonce que, dans un test sans consigne de sécurité, GPT-6 Cyber a respecté ce périmètre dans 99,93 % des cas. Avec les consignes utilisées en production, l’entreprise dit n’avoir observé aucune sortie des limites autorisées. Ces résultats décrivent les tests réalisés, pas une garantie valable pour toute utilisation.

OpenAI recommande ainsi un environnement isolé, l’examen des actions et une supervision humaine pour les usages à risque. Ces précautions portent sur des dimensions différentes : où les essais s’exécutent, ce que les agents font et qui contrôle leur activité. La capacité à enchaîner les opérations ne supprime pas ces points de contrôle.

L’accès initial passe par Daybreak Red, destiné à des chercheurs habilités à mener des tests d’intrusion autorisés, via l’API et Codex. L’autorisation définit le terrain d’intervention ; l’isolation encadre les essais ; la vérification technique établit ce qui a réellement été démontré. Aucun de ces garde-fous ne remplace les deux autres.