OpenAI affirme qu’un système d’IA a découvert 948 failles Linux permettant à des attaquants d’obtenir les droits root

948 voies pour passer d’un compte ordinaire au contrôle total

OpenAI affirme qu’un système de recherche automatisé a découvert 948 vulnérabilités distinctes du noyau Linux susceptibles de permettre à une personne disposant d’un compte utilisateur ordinaire de prendre le contrôle total d’un ordinateur. La campagne a coûté 1 213 430 dollars en crédits d’API d’IA et a généré des correctifs candidats destinés à être examinés par des humains, selon le compte rendu de recherche publié par l’entreprise le 4 novembre 2026.

Les résultats détaillés dans le rapport de recherche d’OpenAI expliquent comment ce chiffre a été obtenu : les agents ont produit 1 169 exploits fonctionnels d’élévation locale de privilèges, puis regroupé les résultats apparentés grâce à l’analyse des variantes et élaboré 948 correctifs distincts. OpenAI utilise ce dernier chiffre pour dénombrer les vulnérabilités uniques.

Une faille d’élévation locale de privilèges permet à une personne ou à un programme déjà actif sur une machine d’obtenir des pouvoirs normalement réservés à son administrateur, appelés droits root. Le noyau Linux est le logiciel central qui gère la mémoire, le matériel et les autorisations d’accès. Le franchissement de cette barrière peut transformer un accès limité en contrôle du système.

OpenAI a testé les exploits sur une distribution Linux couramment utilisée, mais non identifiée, avec ses protections de sécurité habituelles activées. L’entreprise a décrit l’IA alimentant le processus comme un modèle cybernétique à venir, sans donner de date de lancement ni préciser la distribution. Le nombre de découvertes, les coûts et les affirmations concernant de nouvelles techniques d’attaque sont les résultats rapportés par OpenAI elle-même.

Le défi immédiat consiste à faire parvenir les correctifs aux ordinateurs réellement utilisés. Pendant les recherches, des contributeurs Linux corrigeaient déjà ou examinaient des centaines de résultats qui se recoupaient. Des chercheurs humains devaient encore vérifier si chaque exploit visait bien la faille annoncée et si le correctif proposé s’attaquait à sa cause.

Comment les agents ont passé au crible des millions de lignes de code

OpenAI a commencé par sélectionner des parties de Linux accessibles aux utilisateurs ordinaires et importantes pour la sécurité. Des agents de reconnaissance ont repéré 5 034 cibles d’audit couvrant environ 2,8 millions de lignes de code, soit près de 7 % d’un noyau comptant plus de 40 millions de lignes.

Des agents analystes ont ensuite examiné ces cibles, étudié le fonctionnement du code et cherché les endroits où un attaquant pourrait franchir une barrière de sécurité. En 12 heures, ils ont produit 2 308 résultats candidats, après suppression des doublons. La sélection des cibles a coûté 3 426 dollars en crédits d’API ; leur analyse, 316 549 dollars.

Le processus complet comportait cinq étapes : découverte des vulnérabilités, validation dynamique, évaluation de leur exploitabilité, génération de correctifs et examen humain. Chaque étape répondait à une question différente, faisant passer d’un code suspect à un problème de sécurité démontré, puis à une réparation proposée.

Lors de la validation, les agents ont tenté de reproduire chaque problème candidat dans une machine virtuelle isolée à l’aide de Kernel Address Sanitizer, un outil qui détecte certaines erreurs de mémoire. Ils ont observé la sortie des programmes et les journaux système, en ajustant leurs programmes de test jusqu’à déclencher le problème ou à épuiser le nombre de tentatives qui leur était alloué.

En 30 heures, le système a reproduit 1 724 vulnérabilités, soit environ 74,7 % des problèmes candidats. OpenAI a indiqué que bon nombre des autres résultats exigeaient des privilèges plus élevés ou dépendaient de conditions difficiles à déclencher dans le temps imparti. L’entreprise a attribué 3,1 % des résultats candidats à une analyse erronée reposant sur une condition impossible. Les 30 heures correspondaient à l’étape de validation ; l’analyse et l’examen manuel qui ont suivi se sont étendus sur 10 jours.

Ce qu’ont démontré les exploits fonctionnels

L’étape suivante pour OpenAI consistait à déterminer lesquels des bogues reproduits pouvaient révéler des informations ou donner accès aux droits root. Un agent de sélection a réduit le nombre de résultats à 313 candidats à la fuite d’informations et 1 238 candidats potentiels à l’élévation de privilèges.

Des agents chargés de développer des exploits ont produit 291 preuves de concept de fuite d’informations et 1 169 exploits fonctionnels d’élévation de privilèges. Une preuve de concept est un programme de test qui démontre qu’une vulnérabilité peut être déclenchée. Un exploit va plus loin en exploitant la faille pour obtenir un résultat concret en matière de sécurité, comme des privilèges d’administrateur.

Les machines de test conservaient des protections activées, notamment la randomisation des adresses, les restrictions d’accès du noyau à la mémoire utilisateur et les contrôles lors de la copie des données. La randomisation des adresses rend plus difficile pour un attaquant de prédire les emplacements utiles en mémoire. Le maintien de ces protections rapprochait les tests d’une installation de bureau classique.

OpenAI a également testé une version adaptée de l’environnement kernelCTF de Google, dont la surface d’attaque est plus réduite et qui comprend des protections supplémentaires. Cette campagne a produit 25 preuves de concept de fuite d’informations et 21 exploits d’élévation de privilèges en 112 heures, pour un coût d’API d’environ 32 936 dollars. L’adaptation omettait la mesure d’atténuation SLAB_VIRTUAL, incompatible avec la dernière version du noyau utilisée pour le test.

OpenAI a indiqué avoir découvert une vulnérabilité dans QEMU TCG, qui fait partie de l’infrastructure de virtualisation utilisée pour ses tests kernelCTF. La découverte a ainsi conduit à examiner aussi la sécurité de l’environnement de recherche lui-même.

Comparaison entre la campagne d’octobre et les travaux précédents

Les recherches d’OpenAI sur Linux se sont développées au fil de plusieurs expériences menées en 2026. L’entreprise a rattaché ces travaux à Patch the Planet, son initiative visant à aider les responsables de maintenance à découvrir et corriger les vulnérabilités de logiciels largement utilisés.

• Juin 2026 : OpenAI a révélé 24 exploits d’élévation de privilèges sous Linux développés avec GPT-5.5 Cyber.
• Fin juillet 2026 : une campagne utilisant GPT-5.6 Sol a découvert et exploité 166 vulnérabilités uniques d’élévation de privilèges, pour un coût d’API de 513 690 dollars.
• Mi-octobre 2026 : le nouveau modèle cybernétique a produit des exploits couvrant 948 vulnérabilités distinctes d’élévation de privilèges, ainsi que des correctifs candidats, pour un coût de 1 213 430 dollars.
• 4 novembre 2026 : OpenAI a publié son compte rendu du processus et de ses résultats.

La campagne d’octobre a découvert environ 5,7 fois plus de vulnérabilités uniques d’élévation de privilèges que celle de juillet, pour des dépenses environ 2,4 fois supérieures. D’après ces chiffres, les dépenses d’API par découverte unique sont passées d’environ 3 095 à 1 280 dollars.

Les deux campagnes ont examiné la branche principale du noyau Linux la plus récente disponible à l’époque. OpenAI a déclaré que le modèle d’octobre avait découvert nettement plus de vulnérabilités malgré trois mois supplémentaires de corrections et de renforcement du noyau. L’entreprise estime que les logiciels importants devraient faire l’objet de nouveaux examens à mesure que les modèles gagnent en capacités.

Pourquoi obtenir les droits root ne suffisait pas à valider une découverte

OpenAI a rencontré un problème fondamental lors d’une première expérience : 20 des 200 exploits réussis avaient obtenu les droits root en exploitant une vulnérabilité autre que celle attribuée à l’agent. L’attaque fonctionnait, mais l’explication de la faille utilisée était erronée.

Cela avait des conséquences pour la correction. Les chercheurs doivent relier le résultat observé à la bonne cause afin que les responsables de maintenance puissent réparer le code en question. Après avoir découvert ces erreurs d’attribution, OpenAI a ajouté des contrôles indépendants.

Yash Kadakia, fondateur et directeur technique de Security Brigade, a expliqué pourquoi les entreprises ont besoin à la fois de résultats reproductibles et d’explications exactes :

« Obtenir un résultat et expliquer correctement comment on l’a obtenu sont deux choses différentes », a-t-il déclaré.

Les dossiers de recherche finaux d’OpenAI comprenaient une analyse de la cause, un programme de test minimal déclenchant un plantage, un correctif candidat et un exploit complet. Des chercheurs en sécurité humains ont examiné l’exploit, la correction et le niveau de gravité proposé avant de transmettre les résultats aux responsables de maintenance.

La mise au point des correctifs a également nécessité plusieurs itérations. Les premières corrections générées par l’IA introduisaient parfois des changements inutiles ou des compromis de performance, ou ne corrigeaient pas certaines variantes apparentées d’une vulnérabilité. Le test de différentes variantes d’une attaque a aidé les chercheurs à évaluer si une réparation couvrait le problème dans son ensemble.

Ce qu’ont permis d’obtenir 1,2 million de dollars et comment OpenAI en a estimé la valeur

OpenAI a indiqué que la campagne avait coûté au total 1 213 430 dollars, soit environ 1 279 dollars par découverte unique d’élévation de privilèges. Ces chiffres correspondent aux dépenses d’API liées aux modèles et au processus, et non à un bilan complet du travail de recherche et des frais d’exploitation.

L’évaluation de l’exploitabilité a représenté la plus grande part des dépenses. La sélection a coûté 44 194 dollars, tandis que le développement des exploits a coûté 775 929 dollars, dont 691 000 dollars pour les candidats à l’élévation de privilèges et 84 929 dollars pour les candidats à la fuite d’informations.

Les échecs les plus difficiles pouvaient coûter particulièrement cher. OpenAI a fait état d’une dépense moyenne d’environ 3 922 dollars pour chacune des 69 tentatives infructueuses d’élévation de privilèges, contre environ 360 dollars par exploit réussi. Certains cas récalcitrants impliquaient des conditions de concurrence, où le succès dépend de la survenue d’événements dans un ordre ou à un moment précis.

OpenAI a comparé les 948 découvertes aux récompenses historiques des concours Pwn2Own et TyphoonPWN, respectivement de 20 000 et 70 000 dollars pour des exploits d’élévation de privilèges dans le noyau Linux. En appliquant ces montants, l’entreprise a estimé leur valeur théorique entre 18,9 et 66,3 millions de dollars, soit environ 16 à 55 fois le coût de la campagne en API.

L’entreprise a également estimé que ses 21 exploits kernelCTF pourraient rapporter environ 1,5 million de dollars s’ils étaient acceptés par le programme. Ces deux comparaisons sont des estimations conditionnelles des primes, les sommes réellement versées dépendant des règles des programmes et de l’acceptation des exploits. OpenAI a indiqué que ses travaux visaient à mesurer les capacités plutôt qu’à réduire les coûts, et qu’une meilleure conception du processus pourrait diminuer les dépenses.

Dix nouvelles techniques revendiquées, détails non communiqués

OpenAI a étudié un échantillon de 166 exploits et affirme avoir identifié au moins 10 techniques d’exploitation nouvelles pour ses chercheurs et pour les spécialistes externes de l’exploitation du noyau consultés pendant les travaux. Les consignes détaillées ont été retenues pour des raisons de sécurité.

Ces techniques comprenaient deux nouveaux objets permettant de placer des données contrôlées par l’attaquant dans la mémoire du noyau, deux façons d’organiser la mémoire pour améliorer la fiabilité, cinq méthodes d’obtention de privilèges par modification des données et une technique faisant intervenir une confusion de types arbitraire. Une confusion de types se produit lorsqu’un logiciel traite un objet comme s’il était d’une autre nature, ce qui peut donner accès aux mauvaises données ou opérations.

OpenAI a présenté ces résultats comme la preuve que les agents pouvaient élaborer des approches allant au-delà des schémas d’exploitation connus. Cette affirmation repose sur l’examen de l’échantillon par l’entreprise et sur ses échanges avec des spécialistes externes.

Pour les défenseurs, la conséquence concrète est qu’un correctif doit être testé contre des variantes d’attaque apparentées, et pas seulement contre la première démonstration fonctionnelle. OpenAI a indiqué que des itérations guidées par des experts pouvaient aider à produire des correctifs fonctionnels, adaptés au code environnant et résistants aux attaques par variantes.

L’écart entre un correctif intégré au projet et une machine protégée

Les responsables de maintenance Linux agissaient déjà pendant la campagne d’OpenAI. À la fin des 10 jours consacrés à l’analyse et à l’examen manuel, 61 découvertes d’élévation de privilèges avaient été corrigées dans le projet principal, 43 faisaient l’objet de correctifs en cours d’intégration et 299 étaient signalées et discutées publiquement.

Un correctif intégré au projet est une modification acceptée dans le projet principal. Un correctif en cours d’intégration est encore à l’étape de l’examen ou de l’intégration. Les distributeurs Linux doivent ensuite fournir les mises à jour adaptées à leurs clients, qui doivent les installer et activer le noyau corrigé.

OpenAI a indiqué avoir soumis des centaines de rapports et de correctifs, en commençant par les vulnérabilités critiques conformément aux recommandations de la communauté du noyau. L’entreprise n’a pas fourni de bilan complet des mesures correctives pour les 948 découvertes.

Sakshi Grover, directrice de recherche chez IDC, a souligné que la période précédant l’arrivée des correctifs sur les systèmes opérationnels constituait le principal sujet de préoccupation :

« Le risque tient moins aux 948 failles qu’à la durée de la période entre leur découverte et l’arrivée des correctifs en production », a-t-elle déclaré.

Grover a recommandé de donner la priorité aux machines partagées entre plusieurs clients, aux systèmes automatisés de compilation logicielle, aux serveurs à accès partagé, aux plateformes de conteneurs et aux machines des développeurs. Elle a également encouragé les organisations à demander aux distributeurs Linux des calendriers d’intégration des correctifs aux versions prises en charge.

Thomas Di Giacomo, directeur de la technologie et des produits chez SUSE, a déclaré que l’entreprise utilisait des outils d’IA similaires et collaborait avec les communautés amont pour la divulgation et la correction des vulnérabilités. Il a décrit l’approche de SUSE comme une combinaison de plusieurs couches de protection et d’environnements d’exécution applicatifs renforcés.

Un cycle de découverte plus rapide dépasse le cadre des ordinateurs Linux

Selon les chiffres du Google Threat Intelligence Group, 10 740 vulnérabilités ont été divulguées en août 2026, contre 5 045 en janvier. Le nombre de vulnérabilités classées à haut risque est passé de 131 à 350 sur la même période, soit une hausse d’environ 167 %.

Le Centre national de cybersécurité du Royaume-Uni a abordé la découverte assistée par l’IA dans une évaluation publiée le 3 novembre. L’agence a déclaré :

« La large disponibilité des outils cybernétiques fondés sur l’IA a presque certainement entraîné une hausse importante de la découverte de vulnérabilités de type zero-day », a-t-elle indiqué.

Une vulnérabilité zero-day est une faille pour laquelle les défenseurs n’ont pas eu la possibilité de préparer un correctif à l’avance. Le NCSC a indiqué que les outils défensifs fondés sur l’IA avaient accéléré la correction des failles, tout en avertissant que de nombreux systèmes restaient exposés lorsque ces outils n’étaient pas correctement configurés et largement déployés. Les organisations devraient adapter leurs processus de correction et de test à ce rythme plus soutenu.

La présence de Linux dans de nombreux environnements donne à ce problème opérationnel une vaste portée. Le noyau équipe les appareils Android, les infrastructures cloud et les superordinateurs. Les infrastructures blockchain sont également exposées : environ deux tiers des nœuds Ethereum utilisent Linux, selon les chiffres d’ethernodes.org cités dans les articles consacrés à ces découvertes.

Mudit Gupta, directeur technique chez Polygon Labs, a fait valoir que les infrastructures distribuées offrent une meilleure résilience :

La décentralisation apporte une diversité d’infrastructures et une redondance qui rendent les cryptomonnaies bien plus résilientes face à ce type de bogue que les logiciels traditionnels.

Le chercheur en sécurité Caducus a également estimé que les infrastructures de cryptomonnaies étaient devenues plus résilientes à force d’être exposées à des attaques. Pour les opérateurs individuels, la tâche concrète reste de tenir leurs machines à jour et de limiter les dégâts qu’un compte compromis pourrait causer.

OpenAI a recommandé des défenses à plusieurs niveaux, notamment des bacs à sable et des systèmes d’isolation comme Firecracker et gVisor. Son avertissement est direct : un attaquant disposant de ressources importantes et d’un compte ordinaire sur un système d’exploitation auquel les correctifs disponibles n’ont pas été appliqués pourrait transformer cet accès en contrôle root. Une découverte plus rapide des bogues n’est utile que si les correctifs qui en découlent parviennent rapidement aux systèmes concernés.

Points clés

• OpenAI a fait état de 948 vulnérabilités distinctes d’élévation de privilèges sous Linux, après avoir analysé 1 169 exploits fonctionnels et produit des correctifs candidats.
• La campagne d’octobre a coûté 1 213 430 dollars en crédits d’API. L’étape de validation a reproduit 1 724 vulnérabilités candidates en 30 heures.
• Les tests ont été réalisés sur une distribution Linux classique avec les protections standard activées ; ni le modèle ni la distribution n’ont été identifiés.
• Un examen humain restait nécessaire pour vérifier la cause de chaque exploit et évaluer les correctifs proposés.
• Les responsables de maintenance avaient déjà corrigé 61 découvertes dans le projet principal ; 43 faisaient l’objet de correctifs en cours d’intégration et 299 étaient en discussion publique à la fin de l’analyse.
• La priorité immédiate pour les défenseurs est de fournir et d’installer les correctifs, en particulier sur les systèmes partagés où un accès ordinaire pourrait permettre d’obtenir les droits d’administrateur.