En huit jours, deux failles critiques du noyau Linux ont été divulguées : Copy Fail (29 avril 2026) et Dirty Frag (7-8 mai 2026). Toutes deux donnent un accès root à n’importe quel utilisateur local, sur la quasi-totalité des distributions Linux déployées depuis 2017. La première a été trouvée en environ une heure par un outil d’IA offensive. La seconde s’en est directement inspirée. Ce n’est pas un fait divers : c’est le signal qu’un nouveau régime de découverte de vulnérabilités vient de s’installer. Voici ce que ça change pour la sécurité de votre SI, et ce que ça ne change pas.
Que s’est-il passé entre le 29 avril et le 8 mai 2026 ?
Le 29 avril, l’équipe de recherche Theori publie Copy Fail (CVE-2026-31431). Une faille logique dans le sous-système cryptographique du noyau Linux (algif_aead) qui permet à n’importe quel utilisateur non privilégié de devenir root, avec un script Python de 732 octets. La faille est présente dans le code depuis 2017. Aucune race condition, aucune fenêtre temporelle à hitter : l’exploit fonctionne à tous les coups, sur Ubuntu, Debian, RHEL, SUSE, Amazon Linux, sans recompilation.
Le détail qui compte : Theori indique que la vulnérabilité a été identifiée « par environ une heure de scan de leur outil Xint Code sur le sous-système crypto/, avec un seul prompt opérateur, sans harnais d’analyse particulier ». Theori n’est pas un acteur anecdotique, l’équipe a fini 3ème à la finale du DARPA AI Cyber Challenge, une compétition d’un an dédiée à la découverte automatisée de vulnérabilités par l’IA.
Le 7 mai, le chercheur indépendant Hyunwoo Kim (@v4bel) publie Dirty Frag (CVE-2026-43284 et CVE-2026-43500). Une chaîne de deux vulnérabilités dans les sous-systèmes IPsec/ESP et RxRPC, qui obtient le même résultat, root pour un utilisateur local, sur la quasi-totalité des distributions Linux. La publication est faite en urgence, l’embargo coordonné avec les distributions ayant été rompu par un tiers. Aucun patch n’est disponible au moment de la divulgation.
La phrase la plus parlante du document de Kim : « Copy Fail a été la motivation pour démarrer cette recherche. » Il a vu le pattern de Copy Fail, il en a cherché d’autres, il en a trouvé. En huit jours.
En quoi l’IA change-t-elle la recherche de failles ?
Jusqu’ici, la découverte de vulnérabilités à fort impact reposait sur un goulot d’étranglement : il fallait un chercheur humain, expérimenté, capable de lire des dizaines de milliers de lignes de code d’un sous-système et d’y reconnaître un motif suspect. Ce travail prenait des semaines, parfois des mois. Le noyau Linux fait plusieurs dizaines de millions de lignes.
L’IA appliquée à l’analyse de code change ce calcul sur trois points :
D’abord, l’échelle. Un modèle peut parcourir tout le noyau en quelques heures et signaler des motifs qui méritent une lecture humaine. Ce n’est plus l’humain qui cherche les aiguilles, c’est l’humain qui trie les piles qu’on lui ramène.
Ensuite, la transposition de pattern. Quand une faille est publiée, l’IA peut chercher le même mécanisme dans d’autres sous-systèmes. C’est exactement ce qui s’est passé entre Copy Fail et Dirty Frag : un mécanisme d’optimisation introduit en 2017 pour ESP, copié sur RxRPC en 2023, deux portes d’entrée du même type, restées invisibles pendant des années pour les humains, identifiées en quelques jours une fois le pattern décrit.
Enfin, la démocratisation. Theori est une équipe de très haut niveau. Mais Xint Code, ou un équivalent, ne reste pas longtemps une exclusivité. À mesure que les outils d’analyse statique assistée par LLM se diffusent, chez les éditeurs commerciaux comme chez les chercheurs indépendants, le nombre d’acteurs capables de produire ce type de découverte augmente. Côté défense comme côté offense.
L’éditeur CIQ (Rocky Linux) résume ainsi le scénario : « Nous voyons Dirty Frag et l’incident Copy Fail comme un aperçu de ce qui s’annonce. Avec des outils d’IA capables d’analyser des bases de code de la taille du noyau Linux, nous nous attendons à voir arriver des vagues d’exploits comme ceux-ci. »
Faut-il en conclure que tout va s’effondrer ?
Non. C’est important de garder la tête froide.
Ces deux failles sont des escalades de privilèges locales : il faut déjà disposer d’un accès, un compte SSH, un conteneur compromis, un job CI/CD piégé, un shell web, pour pouvoir les exploiter. Elles ne donnent pas un accès initial. La porte d’entrée reste ce qu’elle a toujours été : un email piégé, un mot de passe faible, un service exposé non patché, une dépendance vérolée.
Pour une PME ou une agence dont le SI tient sur quelques serveurs Linux mutualisés et un parc bureautique sous Windows, le scénario à craindre n’est pas qu’un attaquant se réveille un matin avec une 0-day kernel sous le coude. C’est qu’il rentre par la voie habituelle, phishing, RDP exposé, identifiant fuité, puis qu’il utilise ce type de faille pour s’enraciner. La nouveauté n’est pas qu’on devient root après être rentré. C’est que la quantité de chemins disponibles pour devenir root augmente, et que la fenêtre entre divulgation publique et exploitation se réduit.
Ce que ça change concrètement pour votre SI
Trois choses, et trois seulement :
Le délai entre divulgation et exploitation se compresse. Avant, un patch publié pouvait attendre la fenêtre de maintenance du mois suivant. Aujourd’hui, l’écart entre la publication d’un correctif et l’apparition d’un exploit dans les attaques opportunistes se mesure en jours, parfois en heures. Le cycle de patching mensuel devient un risque mesurable.
Les couches profondes ne sont plus un refuge. Pendant des années, on a considéré que le noyau, les bibliothèques de bas niveau, les protocoles éprouvés étaient des zones « stables », vieux, donc audité, donc sûr. Copy Fail montre qu’un bug peut rester dormant neuf ans dans un sous-système crypto utilisé partout. Le code ancien n’est pas du code sûr ; c’est du code qui a échappé à un certain type de lecture, et qui ne va pas échapper au prochain.
La mutualisation devient un facteur de risque amplifié. Conteneurs partageant un même noyau, environnements multi-tenants, serveurs CI/CD avec exécution de code non maîtrisé, hébergements mutualisés grand public : tout ce qui repose sur l’isolation par espace de noms du kernel hérite directement de ses failles. Si vous mettez du code tiers en exécution sur la même machine que vos systèmes critiques, le risque change de nature.
Ce que ça ne change pas
C’est la partie la plus importante de cet article.
L’IA accélère la découverte de failles, mais elle ne remplace pas les fondamentaux de la sécurité opérationnelle. Et ces fondamentaux ne sont pas plus compliqués qu’il y a cinq ans :
- Patcher vite. Un noyau à jour, un parc applicatif à jour, des dépendances suivies. Si votre cycle de patching dépasse 30 jours sur des composants critiques, c’est là qu’il faut investir, pas dans une nouvelle solution.
- Limiter la surface. Un service qui n’est pas exposé ne peut pas être attaqué. Un module noyau qui n’est pas chargé ne peut pas être exploité. Avant de patcher, ce qui n’est pas nécessaire devrait être désactivé.
- Isoler ce qui doit l’être. Les charges sensibles séparées des charges de test. Les comptes administratifs séparés des comptes d’usage. Les machines exécutant du code tiers (CI/CD, hébergement client) séparées du reste.
- Détecter ce que la prévention rate. Centralisation des journaux, supervision des appels système anormaux, alertes sur les élévations de privilèges. Une faille kernel inconnue produit un comportement anormal avant d’aboutir : c’est ce comportement qu’on chasse.
- Sauvegarder hors ligne. Tout ce qui précède peut échouer. Une sauvegarde isolée du SI, testée régulièrement en restauration, reste la seule garantie de revenir à un état connu.
Ces principes ne sont ni nouveaux, ni glamour. Ils ne se vendent pas en encart de salon. Mais ils sont ce qui sépare un SI résilient d’un SI dont la sécurité repose sur l’espoir que personne ne s’intéresse à lui.
L’IA est-elle aussi du côté défense ?
Oui, et de plus en plus. Les mêmes capacités qui permettent à Theori d’auditer le noyau Linux permettent à un éditeur de plateforme de détection d’identifier en quelques minutes un pattern d’exploitation dans un flux de journaux. Cloudflare a publié, dans les heures suivant la divulgation de Copy Fail, un retour d’expérience indiquant que leurs détections comportementales existantes, pas spécifiques à Copy Fail, ont identifié le pattern d’exploitation dès la publication du PoC.
Pour une PME, l’enjeu n’est pas de déployer son propre LLM offensif. C’est de s’assurer que les outils défensifs qu’elle utilise, antivirus, EDR, supervision, hébergeur, intègrent cette capacité d’analyse comportementale. Et que la chaîne de réponse derrière (qui regarde les alertes ? combien de temps après ?) soit prévue.
C’est exactement le sens du référentiel NIST CSF 2.0 : structurer la sécurité autour de cinq fonctions, Identifier, Protéger, Détecter, Répondre, Récupérer, et accepter que la prévention seule ne suffit plus.
Que faire concrètement dans les semaines qui viennent ?
Trois actions immédiates, sans urgence dramatique, mais sans procrastination non plus :
- Vérifier l’état de patching de vos serveurs Linux. Copy Fail et Dirty Frag sont patchés sur les distributions majeures depuis la première semaine de mai. Si vos serveurs n’ont pas redémarré depuis, le correctif n’est pas actif. Ce point seul couvre l’essentiel du risque immédiat.
- Inventorier ce qui exécute du code non maîtrisé sur vos machines. Runners CI/CD, environnements de test partagés, conteneurs hébergeant des charges multi-clients : ce sont les premiers postes de risque pour ce type de faille. Si ce code peut être déplacé sur des machines isolées, faites-le.
- Faire le point sur votre cycle de mise à jour. Pas seulement noyau Linux : applicatif, dépendances, CMS, plugins WordPress, frameworks. L’enjeu n’est pas de patcher demain matin, c’est de pouvoir patcher en moins de 7 jours quand c’est nécessaire. Si ce délai n’est pas atteignable aujourd’hui, c’est ça le sujet de fond.
Si vous voulez aller plus loin que ces trois points, le cadre NIST CSF 2.0 appliqué aux PME donne une structure complète. Et si la maîtrise du cycle de mise à jour est aujourd’hui l’angle mort de votre SI, c’est exactement ce que couvre l’article sur les bonnes pratiques de mise à jour.
En une phrase
L’IA ne réinvente pas la cybersécurité, elle accélère son horloge. Les bonnes pratiques qui fonctionnaient en 2024 fonctionnent encore en 2026, il faut juste les appliquer plus vite et plus rigoureusement qu’avant.
Questions fréquentes
Quelle est la différence entre Copy Fail et Dirty Frag ?
Les deux failles produisent le même résultat, un accès root pour un utilisateur local sur la quasi-totalité des distributions Linux, mais empruntent des chemins différents. Copy Fail (CVE-2026-31431) exploite le module cryptographique algif_aead. Dirty Frag (CVE-2026-43284 et CVE-2026-43500) chaîne deux vulnérabilités dans les sous-systèmes IPsec/ESP et RxRPC. La mitigation appliquée à Copy Fail (blacklist d’algif_aead) ne protège pas contre Dirty Frag : il faut traiter les deux séparément.
Mon entreprise est-elle concernée si nos utilisateurs n’ont pas de compte Linux ?
Probablement, oui. Ces failles requièrent un accès local, mais « accès local » ne signifie pas « employé qui se logge ». Cela inclut : un runner CI/CD qui exécute du code de dépôt Git, un site web vulnérable qui permet à un attaquant d’obtenir un shell limité, un conteneur Docker compromis sur un hôte mutualisé, un service exposé piraté. Toute machine Linux exécutant du code dont vous ne maîtrisez pas l’intégralité de la chaîne est exposée.
Faut-il déployer un EDR pour se protéger contre ce type de faille ?
Pas en première intention. La défense la plus efficace contre Copy Fail et Dirty Frag, c’est le patch : appliqué, il neutralise la faille à 100 %. Un EDR, Endpoint Detection and Response, apporte de la valeur sur les comportements anormaux avant et après exploitation, et reste pertinent en complément. Mais investir dans un EDR avant d’avoir un cycle de patching maîtrisé revient à acheter un système d’alarme pour une maison dont la porte d’entrée n’est pas fermée à clé.
L’IA peut-elle aussi servir la défense à l’échelle d’une PME ?
Oui, mais indirectement. Une PME n’a aucun intérêt à entraîner ses propres modèles de détection : c’est un travail d’éditeur. En revanche, elle bénéficie de l’IA dès qu’elle choisit des outils qui l’intègrent : EDR avec analyse comportementale, supervision avec détection d’anomalies, filtrage anti-phishing avec analyse de contexte. Le bon réflexe n’est pas de demander « as-tu de l’IA ? » à votre prestataire, mais « comment ton outil détecte-t-il une activité que personne n’a encore signée ? ».
