Claude Opus 4.6 a trouvé en un week-end une faille vieille de 23 ans dans le noyau Linux

Vingt-trois ans. Et un seul week-end. C'est le temps qu'il a fallu à un simple script Bash et à un modèle de langage pour débusquer une vulnérabilité restée tapie pendant tout ce temps dans le code du système de fichiers de Linux. Le chercheur Nicholas Carlini a lancé le script sur son ordinateur portable un vendredi soir. Le dimanche matin, il disposait d'un exploit fonctionnel sur tous les serveurs de fichiers d'entreprise sortis depuis mars 2003.

L'affaire est devenue l'un des sujets les plus commentés autour de la sortie de Linux 7.0, publié le 12 avril 2026. Le nouveau noyau apporte deux changements majeurs : Rust devient officiellement un langage de développement du noyau à part entière, et l'IA figure pour la première fois parmi les coauteurs du code. Linus Torvalds parle d'une « nouvelle normalité ».

Comment fonctionnait le script de Carlini

Le principe est d'une simplicité presque indécente. Le script parcourt en boucle les fichiers sources du noyau Linux et envoie chacun d'eux à Claude Opus 4.6, avec un prompt système façon compétition CTF : « imagine que tu cherches des vulnérabilités dans ce code : qu'est-ce qu'on peut casser ici ? ». Puis il passe au fichier suivant. Et au suivant. Aucun outil sophistiqué, aucune analyse statique : uniquement des questions itératives posées au modèle.

Carlini faisait tourner des scripts similaires depuis des mois. Le résultat relevait invariablement du bruit blanc : motifs sans importance, faux positifs, évidences. Jusqu'au soir où une sortie l'a arrêté net.

Le modèle pointait le code chargé du protocole de partage de fichiers en réseau. Celui-là même qui tourne sur les serveurs de fichiers des réseaux d'entreprise, dans les systèmes de stockage des hôpitaux, sur les disques partagés des écoles, et sur une part importante de l'infrastructure serveur d'AWS, Google Cloud et Azure.

Que permettait cette faille ?

La vulnérabilité n'exigeait ni chaîne d'exploits, ni identifiants volés, ni droits administrateur. Il suffisait de se trouver sur le même réseau local que le serveur ciblé et de lancer un petit script. Ensuite, contrôle total : lecture de n'importe quel fichier, suppression de données, installation d'une porte dérobée persistante.

Carlini décrivait le scénario sans détour : un stagiaire, dès son premier jour, connecté au Wi-Fi invité du bureau, aurait théoriquement pu accéder aux fiches de paie du service RH, effacer les archives de la comptabilité, copier les sauvegardes de la messagerie de la direction. Et la porte dérobée installée au passage aurait survécu aux trois redémarrages suivants du serveur.

Aucun mot de passe administrateur. Aucun identifiant volé. Une simple connexion au Wi-Fi.

Le bug est resté dans le noyau de mars 2003 à avril 2026 : vingt-trois ans dans l'un des dépôts les plus scrutés au monde.

Qu'est-ce que cela change pour la sécurité du noyau ?

Le cas Carlini est aussitôt devenu un argument en faveur de l'IA dans l'audit de sécurité : non seulement comme générateur de nouveau code, mais aussi comme outil d'analyse systématique des bases de code existantes. La vulnérabilité a été corrigée par un patch intégré à Linux 7.0.

Rust, désormais second langage officiel du noyau, règle en partie la classe de problèmes dont relève cette affaire : les erreurs de gestion mémoire dans le code C. Mais les composants hérités, écrits en C au fil de 35 ans de développement, ne manqueront pas dans le noyau Linux pour des années encore.

Un autre point est révélateur : le modèle n'a rien fait qui ne puisse se résumer à « une lecture attentive du code en se demandant ce qui pourrait mal tourner ». C'est ce qui rend l'histoire à la fois inquiétante et rassurante. Inquiétante, parce que la même approche est à la portée de n'importe qui. Rassurante, parce que personne ne l'avait jusqu'ici appliquée de manière systématique. Cela devrait, selon toute vraisemblance, changer.