CVE-2026-31431 LA FAILLE LINUX DE 9 ANS QUI MENACE VOS SERVEURS !!

SYNTHÈSE STRUCTURÉE

Une vulnérabilité découverte par intelligence artificielle

L’intervenant souligne que la faille n’a pas été trouvée par un humain analysant le code, mais par un agent IA après une heure de traitement, à partir d’un seul prompt orienté. Il précise : « C’est pas quelqu’un qui a analysé le code et qui a trouvé la faille. Non, c’est un agent IA qui a analysé le code et qui après 1 heure de traitement a trouvé cette vulnérabilité. » Cela remet en perspective la sécurité du noyau open source : le code est auditable, mais cela ne garantit pas l’absence de failles.

Un bug dans la partie cryptographique du noyau

La vulnérabilité, surnommée Copy Fail, exploite un bug dans le sous-système cryptographique du noyau Linux. Elle permet une élévation de privilèges : un utilisateur sans aucun droit (même sans accès à sudo) peut modifier en mémoire le comportement d’un programme système, ici le binaire su. Aucun fichier n’est écrit sur le disque, ce qui rend les antivirus classiques inefficaces.

Aucune modification sur le disque : un contournement des antivirus

L’intervenant insiste sur le fait que l’attaque se déroule uniquement en mémoire : « On n’a pas besoin de toucher à quelconque fichier sur le disque. Ça veut dire que les outils de sécurité qui surveillent l’intégrité des fichiers sur le disque, par exemple un antivirus, il va rien voir. » Seuls des EDR (Endpoint Detection and Response) capables d’analyser les interactions entre processus peuvent détecter ce type d’exploit.

Une faille présente depuis 9 ans (noyau 4.14)

Le problème a été introduit dans le noyau Linux version 4.14, soit il y a environ 9 ans au moment de l’enregistrement. Il est corrigé dans les noyaux suivants :

6.12.85 (LTS)
6.19.12
7.0

Une chronologie exemplaire, mais un POC public

La vulnérabilité a été rapportée le 23 mars à l’équipe sécurité du noyau Linux, dans un comité restreint. Le correctif a été communiqué le 22 avril via la mailing list. Malheureusement, un Proof of Concept (POC) a été rendu public, permettant à quiconque de tester l’exploit sur un système vulnérable. L’intervenant précise : « Si vous prenez ces éléments-là et que vous les testez sur un système vulnérable, vous pouvez être root. »

Démonstration sur Debian : exploitation et correction

L’intervenant montre l’exploitation sur une Debian 13 avec un noyau 6.12.33 (non patché). Il exécute un script Python récupéré via curl et obtient un shell root, confirmé par id et la lecture de /etc/shadow. Après mise à jour du noyau vers 6.12.85 via sudo apt update && sudo apt full-upgrade -y et redémarrage, l’exploit échoue : la commande su demande à nouveau le mot de passe.

Contournement par blacklist du module (Debian)

Si le redémarrage n’est pas possible, l’intervenant recommande de blacklister le module concerné pour ne plus être exposé. Il ne donne pas le nom exact du module dans la transcription, mais la méthode est standard : ajouter une ligne blacklist nom_du_module dans /etc/modprobe.d/.

Cas Red Hat Enterprise Linux : module compilé dans le noyau

Sur RHEL, le module vulnérable est built-in (compilé directement dans le noyau), donc impossible à blacklister. La seule solution est une mesure de contournement qui nécessite un redémarrage : ajouter un paramètre à la ligne de commande du noyau dans /etc/default/grub, puis régénérer GRUB avec sudo grub2-mkconfig -o /boot/grub2/grub.cfg et redémarrer.

SELinux ne protège pas contre cette CVE

L’intervenant teste l’exploit sur une machine RHEL avec SELinux en mode enforcing. Résultat : l’exploitation réussit, il obtient un shell root. Il conclut : « SELinux ne protège rien de tout cela. » Cela montre que même un module de sécurité renforcé n’est pas une protection absolue contre une vulnérabilité noyau.

L’EDR comme bouée de sauvetage en entreprise

Dans son environnement professionnel (250 serveurs RHEL), l’intervenant ne peut pas redémarrer toutes les machines immédiatement. Heureusement, un EDR (Endpoint Detection and Response) a détecté et bloqué l’exploit en tuant le processus Python. Il illustre : « Le DR a kilé, c’est-à-dire il a interrompu le processus et il a mis en quarantaine cette action. » Il recommande vivement l’EDR pour les entreprises, même sur Linux.

Alma Linux : correctif disponible avant Red Hat

Alma Linux, clone de RHEL, a déjà publié un noyau corrigé en dépôt testing (version 6.12.14.52.2). L’intervenant montre l’installation via sudo dnf upgrade kernel* depuis ce dépôt, puis un redémarrage. L’exploit ne fonctionne plus après cette mise à jour. Cela illustre la réactivité des distributions communautaires par rapport à l’éditeur commercial.

CONCEPTS CLÉS

Élévation de privilèges : Action de passer d’un compte utilisateur sans droits à un compte administrateur (root) en exploitant une vulnérabilité.
Proof of Concept (POC) : Code ou script démontrant qu’une vulnérabilité est exploitable, souvent publié après correction pour valider le correctif.
EDR (Endpoint Detection and Response) : Solution de sécurité qui analyse les comportements des processus en mémoire et les interactions entre eux, capable de bloquer des attaques inconnues (zero-day).
Module built-in : Fonctionnalité compilée directement dans le noyau, non chargeable/déchargeable dynamiquement, donc impossible à blacklister.
Patching à chaud (live patching) : Technique permettant d’appliquer un correctif noyau sans redémarrer le système, utilisée notamment par Ksplice ou KernelCare.

CONCLUSION

La CVE-2026-31431 est une faille critique qui démontre que même un noyau open source audité peut contenir des vulnérabilités dormantes pendant des années. Sa découverte par une IA marque un tournant dans la cybersécurité. Pour les administrateurs, la leçon est triple : 1) les correctifs noyau doivent être appliqués rapidement, quitte à redémarrer ; 2) les solutions de sécurité mémoire (EDR) sont indispensables en environnement professionnel ; 3) les distributions communautaires peuvent parfois réagir plus vite que les éditeurs commerciaux. Comme le résume l’intervenant : « Linux par conception est plus sécurisé que Windows sur un certain nombre d’éléments, mais ça ne dispense pas de protéger ces serveurs par des systèmes de sécurité. »