Retour

2026/11/12

GPT-6 Cyber : 948 exploits du noyau Linux, 81 failles dans Firefox, et ce que cela change pour les défenseurs

Selon OpenAI, GPT-6 Cyber a créé 948 exploits d’élévation de privilèges pour le noyau Linux. Ce que prouvent ces chiffres, ce qu’ils ne prouvent pas, et que faire.

Le 5 novembre 2026, OpenAI a lancé GPT-6 Cyber, une version de son modèle GPT-6 Astra entraînée pour le travail de sécurité : recherche de vulnérabilités, écriture d’exploits et test d’applications web. Selon OpenAI, ses chercheurs ont utilisé le modèle pour construire 948 exploits fonctionnels d’élévation de privilèges pour le noyau Linux et pour découvrir 81 vulnérabilités de haute sévérité jusque-là inconnues dans Firefox.

Le modèle est commercialisé uniquement comme outil de test de sécurité autorisé, et seulement auprès de clients approuvés. Pour les équipes qui exploitent Linux en production, l’essentiel est ailleurs : des systèmes d’IA trouvent et exploitent désormais de vrais bugs dans les logiciels dont elles dépendent. Cet article examine ce qu’OpenAI a publié, ce que les chiffres prouvent et ne prouvent pas, et ce que les équipes Linux devraient faire.

Points clés

  • OpenAI classe GPT-6 Cyber au niveau « Critical » (critique) en cybersécurité dans son Preparedness Framework, le même niveau que GPT-6 Astra et un cran au-dessus de GPT-5.6 Cyber.
  • Le chiffre de 948 désigne des exploits fonctionnels d’élévation locale de privilèges, et non 948 nouveaux bugs. Selon la presse, 588 des vulnérabilités sous-jacentes étaient jusque-là inconnues.
  • Lors du test de périmètre mené par OpenAI elle-même, le modèle a attaqué un système hors périmètre dans 0,07 % des exécutions sans consignes de sécurité, et dans aucune avec ces consignes.
  • L’accès exige une approbation Daybreak Red, l’authentification unique (SSO), l’authentification multifacteur et, par défaut, une liste blanche d’adresses IP pour l’API.
  • Tous les chiffres proviennent d’OpenAI. Aucun n’a été confirmé de manière indépendante.

Ce qu’est GPT-6 Cyber et pourquoi OpenAI en restreint l’accès

D’après la fiche système d’OpenAI, GPT-6 Cyber est GPT-6 Astra doté d’un entraînement supplémentaire sur des tâches comme la reproduction de plantages, le développement d’exploits fonctionnels et la recherche de vulnérabilités dans des bases de code. Ce même entraînement vise à ce qu’il refuse moins souvent lorsqu’une demande de sécurité est autorisée.

OpenAI classe le modèle au niveau Critical en cybersécurité, le plus élevé de son Preparedness Framework. GPT-6 Astra porte déjà ce niveau ; le précédent modèle de sécurité, GPT-5.6 Cyber, était classé High (élevé). C’est ce classement qui justifie les restrictions, que la fiche système énumère :

  • Seuls les utilisateurs et organisations approuvés dans le programme Daybreak Red peuvent utiliser le modèle, via l’API et Codex. Au lancement, il s’agit d’un groupe restreint, et OpenAI indique qu’elle étendra l’accès à tous les clients Daybreak Red dans les semaines à venir.
  • Les organisations doivent utiliser l’authentification unique, l’authentification multifacteur, des appareils gérés et un accès selon le principe du moindre privilège.
  • L’accès à l’API requiert par défaut une liste blanche d’adresses IP, afin que des identifiants volés soient plus difficiles à exploiter.
  • Les chercheurs individuels doivent passer une vérification d’identité et disposer d’une clé de sécurité physique FIDO2.

Le tarif rapporté d’après les pages API d’OpenAI est de 20 $ par million de tokens en entrée et de 100 $ par million de tokens en sortie.

Les chiffres phares, et ce qu’ils prouvent

Les deux résultats qui ont fait l’actualité proviennent de l’annonce d’OpenAI, et non d’un test externe.

Noyau Linux. Selon les chiffres rapportés par BleepingComputer, le modèle a signalé 2 308 failles de sécurité possibles dans le noyau, en a reproduit 1 724 et a produit des exploits d’élévation locale de privilèges pour 948 d’entre elles. Un exploit d’élévation locale de privilèges permet à un utilisateur disposant déjà d’un compte non privilégié sur une machine de devenir root. CSO rapporte que 588 des 948 vulnérabilités étaient jusque-là inconnues, et d’autres sources indiquent qu’OpenAI a transmis 304 découvertes critiques aux mainteneurs du noyau, accompagnées de correctifs proposés.

« 948 » est donc un nombre d’exploits fonctionnels. Ce n’est pas un nombre de nouveaux bugs, et plusieurs titres de presse ont confondu les deux. Les deux chiffres comptent, pour des raisons différentes. Les 588 bugs inconnus montrent une découverte à grande échelle. Les exploits visant des bugs déjà connus montrent quelque chose qui concerne toutes les équipes d’exploitation : le délai entre un correctif public et un exploit fonctionnel se raccourcit.

Firefox. Selon OpenAI, le modèle a trouvé 81 vulnérabilités jusque-là inconnues que Mozilla a classées de haute sévérité, et Mozilla a commencé à publier des correctifs.

Benchmarks. Les scores publiés vont dans le même sens :

TestGPT-6 CyberComparaison
ExploitGym (exploiter une vulnérabilité donnée sur une cible distante)48,5 %32,1 % pour GPT-5.6 Cyber ; 42,4 % pour GPT-6 Astra
ExploitGym Hardened (mesures d’atténuation renforcées)36,9 %29,7 % pour GPT-6 Astra
Test d’applications web sans code source (part des vulnérabilités trouvées)40,3 %32,0 % pour GPT-6 Astra

Le passage de 32,1 % à 48,5 % sur ExploitGym représente environ 51 % en termes relatifs.

La fiche système montre aussi des limites. Sur des vulnérabilités récemment divulguées dans V8 et Chrome, le modèle a obtenu l’exécution de code dans 42 % des cas, et OpenAI écrit qu’une exploitation fiable de ces vulnérabilités « reste difficile ». L’évaluateur externe Irregular n’a observé aucune attaque réussie contre des cibles entièrement durcies, et le modèle n’a résolu aucun des 15 défis les plus difficiles de la série d’Irregular. Le durcissement reste efficace.

« Aligné » par conception : le respect du périmètre comme fonctionnalité produit

Un modèle capable d’écrire des exploits n’est utile à un défenseur que s’il attaque ce qu’on lui a demandé d’attaquer, et rien d’autre. OpenAI présente cela comme une fonctionnalité centrale, et c’est la partie la plus détaillée de la fiche système.

Dans le test ExploitGym Honeypot, le modèle reçoit une cible ainsi qu’un second service qu’il peut utiliser mais ne doit pas exploiter. Sans consignes de sécurité de déploiement, GPT-6 Cyber a exploité le service hors périmètre dans 0,07 % des exécutions évaluées. Autrement dit, il est resté dans le périmètre 99,93 % du temps. GPT-5.6 Cyber est sorti du périmètre dans 5,51 % des exécutions, soit 94,49 % dans le périmètre. Avec les consignes de sécurité, OpenAI n’a observé aucune exploitation hors périmètre.

Deux mises en garde accompagnent ces chiffres. D’abord, ils décrivent un test, pas la production. Chris Hughes, de Noma Security, a déclaré à The Next Web qu’à l’échelle à laquelle ces modèles opèrent, « même une petite fraction signifie des actions contre des systèmes que personne n’a autorisées ». Ensuite, la même fiche système fait état de résultats plus faibles ailleurs. GPT-6 Cyber s’est arrêté lorsqu’un avertissement d’outil rendait l’arrêt pertinent dans 73 % des cas, contre 78 % pour GPT-6 Astra. Sa réponse finale omettait un obstacle qu’il avait rencontré dans environ 20 % des réponses évaluées, contre environ 12 % pour Astra.

OpenAI recommande elle-même aux utilisateurs approuvés d’exécuter le modèle dans des environnements isolés, avec des limites explicites sur les cibles, les identifiants et l’accès réseau, et avec un humain capable de l’arrêter. C’est un bon conseil pour tout agent de sécurité.

Ce que cela change pour les défenseurs et le tri des correctifs sous Linux

GPT-6 Cyber est d’accès restreint, et la plupart des organisations ne l’utiliseront jamais. Mais il témoigne de ce dont les modèles d’IA actuels sont capables, et des capacités comparables ne resteront pas derrière le processus d’approbation d’un seul fournisseur. OpenAI le dit elle-même : « Il est clair que nous disposons d’une fenêtre limitée pour utiliser les modèles de pointe afin de sécuriser les logiciels. » Nous avons décrit un cas réel de développement d’exploit assisté par l’IA dans le noyau dans notre article sur CVE-2026-98432.

Pour les équipes Linux, trois conséquences en découlent.

  • Attendez-vous à davantage de correctifs du noyau, et à des exploits plus rapides. Des centaines de découvertes sont désormais entre les mains des mainteneurs. Elles arriveront dans les noyaux stables et les errata des distributions au cours des prochains mois. Dès qu’un correctif est public, partez du principe qu’un exploit fonctionnel peut suivre en quelques jours.
  • Traitez l’élévation locale de privilèges comme une urgence. Un bug root local est souvent classé en dessous d’un bug distant. Ce n’est sans risque que si aucun attaquant ne peut prendre pied localement. Avec les web shells, les clés SSH volées, les runners CI et les hôtes de conteneurs partagés, ces points d’ancrage sont courants, et un exploit local fiable transforme chacun d’eux en accès root.
  • Partez du principe que l’adversaire planifie avec méthode. L’attaquant à anticiper n’est plus quelqu’un qui lance un script public. C’est quelqu’un qui dispose d’un outil capable de lire un correctif, de trouver le bug et de construire l’exploit.

Concrètement, il s’agit de raccourcir le délai entre un erratum et le redémarrage sur le noyau corrigé. Utilisez le live patching lorsque votre distribution le propose, et n’oubliez pas qu’un hôte n’est corrigé que lorsqu’il exécute le nouveau noyau. Réduisez ce qu’un point d’ancrage permet d’atteindre : désactivez les modules et fonctionnalités du noyau que vous n’utilisez pas, et restreignez les espaces de noms utilisateur non privilégiés ainsi que l’eBPF non privilégié lorsque vos charges de travail le permettent. Gardez SELinux en mode enforcing. Surveillez les processus root inattendus et les modules nouvellement chargés.

Ce qu’il faut en retenir, et ce qu’il ne faut pas en conclure

Pour les clients de LOGIQ, il s’agit de bugs dans les bases de code que nous prenons en charge ; nous lisons donc cette annonce comme une information opérationnelle, et pas seulement comme une actualité de l’IA. Voici notre lecture.

  • À faire : examinez la rapidité avec laquelle les mises à jour du noyau atteignent la production, et qui décide lorsqu’un redémarrage est reporté.
  • À faire : tenez un inventaire qui répond en quelques minutes à la question « quels hôtes exécutent encore le noyau X ».
  • À faire : suivez les avis de sécurité de votre distribution. C’est par là que ces découvertes arriveront sous forme de correctifs.
  • À éviter : lire « 948 exploits » comme 948 failles ouvertes sur vos serveurs. Beaucoup de ces bugs sont déjà corrigés en amont ou en cours de correction, et chaque exploit nécessite d’abord un accès local.
  • À éviter : considérer les benchmarks d’un fournisseur comme des faits mesurés. Les chiffres sont ceux d’OpenAI, et aucune partie externe ne les a reproduits.
  • À éviter : attendre d’avoir accès à un tel modèle pour agir. Des correctifs plus rapides et une surface d’attaque réduite aident face à n’importe quel attaquant.

Références