Les agents d'OpenAI ont trouvé 948 chemins vers root sous Linux, à 1279 dollars pièce

Imaginez un serveur sur lequel l'attaquant ne dispose que d'un modeste compte utilisateur : il a, par exemple, pénétré dans l'un de vos conteneurs ou obtenu l'accès à un environnement de test. Une vulnérabilité de type LPE (local privilege escalation, élévation de privilèges) transforme ce compte en root, c'est-à-dire en contrôle total de la machine. C'est précisément ce type de failles qu'OpenAI a cherché dans le noyau Linux à l'aide d'agents autonomes.

Sur 1724 vulnérabilités confirmées, 948 ont abouti à des exploits d'élévation de privilèges fonctionnels, et l'ensemble du run a coûté 1 213 430 dollars de crédits API, soit environ 1279 dollars par exploit de ce type. Si Linux tourne chez vous en production, et c'est le cas de la plupart des entreprises, cette actualité vous concerne directement.

OpenAI a publié une analyse intitulée « A thousand fewer paths to root » (« mille chemins vers root en moins »). Le travail a été réalisé par un modèle cyber qui n'est pas encore sorti. Le billet le présente comme upcoming : sa sortie n'est donc peut-être pas très lointaine.

Comment fonctionne le pipeline

Les chercheurs ne se sont pas contentés de demander au modèle de « jeter un œil au code ». Ils ont bâti autour de lui un pipeline autonome en plusieurs étapes, comparable à une équipe où chacun a son rôle, mais sans aucun humain :

• certains agents choisissent la portion de code qui mérite d'être examinée ;
• d'autres la scannent à la recherche de vulnérabilités ;
• d'autres encore reproduisent les trouvailles dans des environnements isolés, afin de s'assurer que la faille est réelle et non une hallucination du modèle ;
• l'étape suivante vérifie si la faille est réellement exploitable ;
• la dernière génère les correctifs.

L'étape de reproduction est ici la plus importante. Le grand problème des scanners automatiques et des relecteurs LLM, c'est qu'ils produisent des montagnes de faux positifs, et les équipes s'enlisent dans le tri de ces déchets. Quand chaque trouvaille est confirmée par un exploit qui fonctionne, le bruit disparaît : le bug se déclenche ou il ne se déclenche pas.

Chiffres et coût

D'après le billet, le pipeline a été lancé sur le noyau Linux, apparemment de façon seulement partielle. Résultat : 1724 vulnérabilités confirmées et reproduites, dont 948 sont devenues des exploits d'élévation de privilèges fonctionnels.

Les 1 213 430 dollars peuvent sembler élevés, mais l'auteur du billet propose une comparaison avec le marché. Au concours de hacking Pwn2Own, un tel exploit était historiquement payé environ 20 000 dollars, et environ 70 000 à TyphoonPWN. En multipliant par 948, on obtient de 18,9 à 66,3 millions de dollars. Autrement dit, ce que les agents ont trouvé coûterait environ 15 à 55 fois plus cher s'il avait été acheté au tarif de ces concours que ce qu'a coûté le run.

Une réserve s'impose : il s'agit d'une estimation de l'auteur du billet, pas d'une grille tarifaire. Les primes des concours et la valeur de marché réelle d'un exploit sont deux choses différentes, et les 948 trouvailles peuvent varier fortement en gravité et en conditions d'exploitation. Pour les détails, mieux vaut se référer à la source primaire.

Que faire concrètement

Premièrement, l'économie de la recherche de vulnérabilités change. Auparavant, un exploit sérieux pour le noyau exigeait des semaines de travail d'un spécialiste rare. Désormais, c'est une ligne de dépense en API, qui passe à l'échelle avec le budget. Cela joue dans les deux sens : les défenseurs trouvent et corrigent les failles plus vite, mais la barrière d'entrée baisse aussi pour les attaquants, s'ils ont accès à des modèles comparables.

Deuxièmement, la fenêtre entre l'apparition d'une vulnérabilité et son exploitation massive va très probablement se réduire. Repousser les mises à jour du noyau sur les serveurs et les hôtes de conteneurs devient plus coûteux : il vaut la peine de revoir votre politique de correctifs.

Troisièmement, l'approche est transposable à votre propre code. Le schéma « trouver, reproduire dans un bac à sable, confirmer l'exploitabilité, proposer un correctif » ne s'applique pas qu'au noyau. Pour ceux qui construisent des agents pour le code et la sécurité, l'essentiel à retenir est le suivant : la valeur ne vient pas d'un seul modèle performant, mais des étapes de vérification autour de lui, qui écartent les fausses trouvailles.

Ce que le billet laisse dans le flou : combien de failles découvertes sont déjà corrigées en amont (upstream), quelle partie exacte du noyau a été scannée, et quand et à quelles conditions le modèle lui-même sortira. Pour l'instant, il s'agit d'une démonstration de force, pas d'un produit prêt à l'emploi. Mais la direction est claire : la recherche automatisée de vulnérabilités cesse d'être un jouet et devient un processus industriel.