OpenAI teste un pipeline IA contre des failles Linux

OpenAI a indiqué le 4 novembre 2026 avoir trouvé 948 vulnérabilités locales d’élévation de privilèges dans Linux grâce à un pipeline prototype reposant sur un futur modèle cyber. L’expérience, menée à la mi-octobre 2026 sur des machines virtuelles isolées, montre qu’une IA peut désormais enchaîner découverte, exploitation et proposition de correctifs sur un codebase massif. Les failles repérées pouvaient donner un accès root à un utilisateur non privilégié. Et sur Linux, ce n’est jamais le genre de détail que l’on range au fond d’un tiroir.

Un test pensé pour mesurer la chaîne complète, pas seulement le repérage

OpenAI n’a pas testé un système artificiellement affaibli. Les essais se sont déroulés sur un système d’exploitation desktop standard, avec SMEP, SMAP, KASLR et HARDENED_USERCOPY activés, dans des VM isolées. Le choix de Linux s’explique aussi par sa taille : le noyau dépasse 40 millions de lignes de code et alimente des smartphones Android, des infrastructures cloud et des supercalculateurs.

Le pipeline relie plusieurs étapes : sélection des cibles, analyse du code, validation dynamique, estimation de l’exploitabilité, génération de patchs, puis revue humaine. Les agents Scout repèrent les zones accessibles à des utilisateurs peu privilégiés et jugées sensibles sur le plan sécurité. Les agents Analyst examinent ensuite ces cibles, puis les agents Triage génèrent et affinent des preuves de concept dans des VM avec Kernel Address Sanitizer, afin de conserver des traces d’exécution plutôt que de s’en remettre uniquement à l’analyse statique.

Des failles à la pile de travail, puis à la pile de correctifs

Chaque dossier de recherche complet contient une analyse de cause racine, une preuve de concept minimale provoquant un crash, un correctif candidat et un exploit complet. OpenAI dit avoir sélectionné 5 034 cibles d’audit couvrant environ 2,8 millions de lignes, soit 7 % du noyau. Les analystes ont produit 2 308 constats candidats dédupliqués en 12 heures, puis la validation dynamique a reproduit 1 724 vulnérabilités en 30 heures.

La suite a été plus concrète encore : 291 preuves de concept pour fuites d’informations et 1 169 exploits locaux fonctionnels, selon OpenAI. L’étape d’analyse par variantes a ensuite produit 948 correctifs distincts, que l’entreprise compte comme 948 failles uniques. Ces correctifs restent toutefois des candidats soumis à revue des mainteneurs, et non des patchs fusionnés en amont.

Pourquoi le chiffre de 948 ne raconte pas toute l’histoire

OpenAI précise que plusieurs résultats portaient sur les mêmes vulnérabilités sous des formes différentes. D’où l’écart entre le nombre d’exploits bruts et le total final de failles uniques. L’entreprise dit aussi avoir identifié 61 LPE déjà corrigées upstream, 43 avec des patchs en préparation et 299 déjà rendues publiques ou discutées à la fin du scan de dix jours et de l’analyse manuelle. Le message adressé aux mainteneurs est clair : il faut revalider les résultats sur le code actuel, merges ultérieurs compris, sous peine de remonter des doublons ou des failles déjà traitées.

Dans un premier cycle, OpenAI a aussi repéré un problème méthodologique plus embarrassant qu’il n’y paraît : 20 exploits “réussis” sur 200 obtenaient un shell root via une autre 0-day que la vulnérabilité assignée. L’équipe a ensuite resserré les consignes et ajouté une vérification indépendante du chemin d’exploitation. Même un root shell peut mentir un peu, visiblement.

La qualité du patch compte autant que l’exploit

Les patchs générés trop vite pouvaient être corrects sur le fond tout en ajoutant du code inutile, en dégradant les performances, en s’écartant des conventions du projet ou en couvrant imparfaitement les variantes. OpenAI dit avoir amélioré la qualité des correctifs grâce à des instructions supplémentaires et à l’itération, mais les chercheurs humains continuent de valider l’exploit, le patch et la sévérité proposée avant tout envoi aux mainteneurs.

Ce point compte pour les équipes de sécurité comme pour les mainteneurs Linux. Le vrai goulot d’étranglement ne se situe plus seulement dans la génération d’indices, mais dans la preuve qu’un chemin d’attaque est réel, reproductible et corrigeable sans bruit inutile. C’est aussi ce qui distingue une recherche exploitable défensivement d’un déluge de signalements difficiles à trier.

Combien ça coûte, et que disent les comparaisons ?

OpenAI estime que la campagne de mi-octobre 2026 a coûté 1,213 million de dollars en crédits API, soit 1 279 dollars par LPE unique. À titre de comparaison, une session GPT-5.6 Sol menée fin juillet 2026 avait trouvé 166 LPE uniques pour 513 690 dollars. Le gain annoncé dépasse donc un facteur cinq sur les failles inédites, malgré trois mois de durcissement entre les deux scans.

L’entreprise indique aussi avoir observé, sur un échantillon de 166 exploits, dix techniques jugées nouvelles par son équipe et par des experts tiers en exploitation du noyau. Les détails techniques ont été volontairement retenus pour des raisons de sécurité. Une autre expérience, adaptée à kernelCTF, a produit 25 preuves de fuite d’informations et 21 exploits LPE en 112 heures pour environ 32 936 dollars de crédits API. Le test a dû retirer la mitigation SLAB_VIRTUAL, jugée incompatible avec le noyau ciblé, et le montant d’environ 1,5 million de dollars de récompense reste conditionnel à l’acceptation des 21 vulnérabilités. Les règles de Google kernelCTF prévoient, elles, 71 337 dollars par exploit éligible, avec un taux de stabilité d’au moins 70 % sur 20 exécutions.