CVE-2026-31431 : La faille Linux qui menace vos serveurs
Bonjour à tous, ici Adrien,
Aujourd'hui, dans cet article, faisons un peu de science-fiction (ou pas)...
imaginez une faille capable de vous donner les pleins pouvoirs sur votre système Linux. Je ne parle pas d'un exploit sudo, pis de toute façon vous n'y avez même pas accès sur ce système.
Vous êtes un simple utilisateur et vous pouvez devenir root sans même toucher au moindre fichier sur le disque. Même une distribution immuable pourrait être vulnérable.
C'est exactement ce que permet la CVE-2026-31431, une vulnérabilité critique découverte dans le noyau Linux.
Je ne vais pas faire d'analyse d'expert ici, l'idée est de vous donner mon avis d'administrateur système. Avec plus de 250 serveurs sous ma responsabilité au taf, quand on voit un tel truc passer, il faut se poser les bonnes questions et comprendre comment cela nous impacte selon notre contexte.
Cette faille est d'autant plus impressionnante qu'elle est présente depuis le noyau 4.14, c’est-à-dire qu'elle est passée sous les radars pendant neuf ans!! D'ailleurs on sait que le noyau Linux est Opensource. Mais ce n'est pas parce que le code est consultable par tous que Linux est forcément plus sécure que Windows ou MacOS. La preuve, tout le monde pouvait auditer ce code et pourtant la faille était là.
Ce qui m'a interpellé aussi, c'est la façon dont elle a été trouvée. Ce n'est pas un humain qui a trouvé l'erreur après des jours d'analyse, mais un agent IA. Après seulement une heure de traitement et à partir d'un seul prompt bien formulé, l'IA a non seulement trouvé la vulnérabilité, mais a aussi produit l'exploit pour la valider.
Quelques infos sur la faille...
Pour entrer juste un peu dans le détail, cette vulnérabilité appelée "Copy Fail" exploite un bug dans la partie cryptographique du noyau, plus précisément l'interface algif_aead. Cela permet une élévation de privilège où un utilisateur sans aucun droit va modifier en mémoire le comportement d'un programme système comme "su". Comme tout se passe en mémoire vive, dans ce qu'on appelle le Page Cache, on ne touche à rien sur le disque. De fait, les éventuels outils de sécurité comme un antivirus qui surveille l'intégrité des fichiers, ne verront absolument rien. Il faut donc des programmes capables d'analyser les interactions en mémoire pour bloquer l'exploitation.
Les mainteneurs du noyau (Greg Kroah-Hartman) ont annoncé des correctifs publiés officiellement fin avril pour les versions LTS et les noyaux récents. (fixé à partir du 6.18.22, 6.19.12 et 7.0). Je vous mets dans le descriptif de l'article.
La chronologie montre que ce n'est pas une faille 0-day car le rapport a été fait dès le mois de mars. Le fix date du 22 avril, mais depuis le 29 avril, un Proof of Concept est disponible publiquement. Cela pose un vrai problème car certains éditeurs de distributions sont lents à pousser les mises à jour, et tant que le patch n'est pas appliqué, les systèmes restent exposés.
Chez Debian par exemple, au 1er Mai, date de rédaction de cet article, c'est fixé pour la version Trixie, mais les versions stables comme Bookworm ou Bullseye sont encore vulnérables.
A propos de Red Hat Enterprise Linux et des protections
Le cas de Red Hat Enterprise Linux est particulièrement intéressant pour moi car c'est mon environnement de travail quotidien. Sur RHEL, les versions 8, 9 et 10 sont affectées et il n'y a pas encore de correctif disponible dans le noyau officiel (au 1er mai je le rappelle).
Contrairement à Debian, on ne peut pas simplement blacklister le module fautif car il est directement compilé dans le noyau. La seule solution est une mesure de contournement qui nécessite de modifier les arguments du grub et de rebooter la machine.
J'ai aussi testé le comportement de SELinux en mode "enforcing", et malheureusement, il ne protège pas de cette faille particulière ; l'exploit Python passe outre et donne l'accès root malgré tout !
Vis ma vis d'admin système au taf...
Dans mon boulot, j'administre plus de 250 serveurs, principalement sous Red Hat Enterprise Linux. Même s'il n'y a pas de correctifs sur RHEL, je dors sur mes deux oreilles grâce à notre EDR !
Lors de mes tests, l'EDR a analysé l'interaction anormale du processus Python et a immédiatement "killé" l'action. C'est lui qui me sauve les fesses en entreprise.
Donc même si les systèmes sont vulnérables niveau "kernel", ces "super-antivirus" qui sont aujourd'hui incontournables en entreprise, permettent de limiter l'exposition en attendant le correctif, que je me dépêcherai d'appliquer lors d'une campagne de mise à jour exceptionnelle !
Un EDR n'empêche pas de mettre à jour ses systèmes évidemment ! Mettre à jour ne cause pas des problèmes, ça les règle... normalement !
A propos des clones de Red Hat Enterprise Linux...
Pour les clones (car j'utilise Alma Linux pour le serveur VPS de Linuxtricks), un noyau corrigé est déjà disponible en test. Evidemment, bien que Red Hat n'ait rien proposé, vu qu'Alma Linux est basée sur CentOS Stream, et que ce n'est pas un clone 1:1 de RHEL, ils peuvent intégrer des correctifs et des améliorations "à leur sauce".
J'ai vérifié sur mon propre serveur : après la mise à jour, l'exploit échoue et le système me redemande mon mot de passe.
Toutes les infos ici : https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/
Mais entre le 29 avril et le 1er mai, ça reste toujours trop lent pour fixer le souci !
Conclusion
Même s'il faut un accès sur le serveur pour exploiter la vulnérabilité, elle peut être combinée à une autre vulnérabilité qui permet d'obtenir un shell sur la machine.
Aussi, elle peut être utilisée par quelqu'un qui n'a que les droits utilisateurs sur le système.
L'IA permet d'améliorer la détection des failles, mais rien n'empêche une personne mal-intentionnée de l'utiliser pour en découvrir sans en avertir les mainteneurs du logiciel. Donc l'intelligence artificielle rebat les cartes de la sécurité informatique.
La sécurité est une course permanente : surveillez vos logs et surtout, mettez à jour !
J'espère que ce petit article vous a plu !
Aujourd'hui, dans cet article, faisons un peu de science-fiction (ou pas)...
imaginez une faille capable de vous donner les pleins pouvoirs sur votre système Linux. Je ne parle pas d'un exploit sudo, pis de toute façon vous n'y avez même pas accès sur ce système.
Vous êtes un simple utilisateur et vous pouvez devenir root sans même toucher au moindre fichier sur le disque. Même une distribution immuable pourrait être vulnérable.
C'est exactement ce que permet la CVE-2026-31431, une vulnérabilité critique découverte dans le noyau Linux.
Je ne vais pas faire d'analyse d'expert ici, l'idée est de vous donner mon avis d'administrateur système. Avec plus de 250 serveurs sous ma responsabilité au taf, quand on voit un tel truc passer, il faut se poser les bonnes questions et comprendre comment cela nous impacte selon notre contexte.
Cette faille est d'autant plus impressionnante qu'elle est présente depuis le noyau 4.14, c’est-à-dire qu'elle est passée sous les radars pendant neuf ans!! D'ailleurs on sait que le noyau Linux est Opensource. Mais ce n'est pas parce que le code est consultable par tous que Linux est forcément plus sécure que Windows ou MacOS. La preuve, tout le monde pouvait auditer ce code et pourtant la faille était là.
Ce qui m'a interpellé aussi, c'est la façon dont elle a été trouvée. Ce n'est pas un humain qui a trouvé l'erreur après des jours d'analyse, mais un agent IA. Après seulement une heure de traitement et à partir d'un seul prompt bien formulé, l'IA a non seulement trouvé la vulnérabilité, mais a aussi produit l'exploit pour la valider.
Quelques infos sur la faille...
Pour entrer juste un peu dans le détail, cette vulnérabilité appelée "Copy Fail" exploite un bug dans la partie cryptographique du noyau, plus précisément l'interface algif_aead. Cela permet une élévation de privilège où un utilisateur sans aucun droit va modifier en mémoire le comportement d'un programme système comme "su". Comme tout se passe en mémoire vive, dans ce qu'on appelle le Page Cache, on ne touche à rien sur le disque. De fait, les éventuels outils de sécurité comme un antivirus qui surveille l'intégrité des fichiers, ne verront absolument rien. Il faut donc des programmes capables d'analyser les interactions en mémoire pour bloquer l'exploitation.
Les mainteneurs du noyau (Greg Kroah-Hartman) ont annoncé des correctifs publiés officiellement fin avril pour les versions LTS et les noyaux récents. (fixé à partir du 6.18.22, 6.19.12 et 7.0). Je vous mets dans le descriptif de l'article.
La chronologie montre que ce n'est pas une faille 0-day car le rapport a été fait dès le mois de mars. Le fix date du 22 avril, mais depuis le 29 avril, un Proof of Concept est disponible publiquement. Cela pose un vrai problème car certains éditeurs de distributions sont lents à pousser les mises à jour, et tant que le patch n'est pas appliqué, les systèmes restent exposés.
Chez Debian par exemple, au 1er Mai, date de rédaction de cet article, c'est fixé pour la version Trixie, mais les versions stables comme Bookworm ou Bullseye sont encore vulnérables.
A propos de Red Hat Enterprise Linux et des protections
Le cas de Red Hat Enterprise Linux est particulièrement intéressant pour moi car c'est mon environnement de travail quotidien. Sur RHEL, les versions 8, 9 et 10 sont affectées et il n'y a pas encore de correctif disponible dans le noyau officiel (au 1er mai je le rappelle).
Contrairement à Debian, on ne peut pas simplement blacklister le module fautif car il est directement compilé dans le noyau. La seule solution est une mesure de contournement qui nécessite de modifier les arguments du grub et de rebooter la machine.
Code BASH :
grubby --update-kernel ALL --args='initcall_blacklist=algif_aead_init'
J'ai aussi testé le comportement de SELinux en mode "enforcing", et malheureusement, il ne protège pas de cette faille particulière ; l'exploit Python passe outre et donne l'accès root malgré tout !
Vis ma vis d'admin système au taf...
Dans mon boulot, j'administre plus de 250 serveurs, principalement sous Red Hat Enterprise Linux. Même s'il n'y a pas de correctifs sur RHEL, je dors sur mes deux oreilles grâce à notre EDR !
Lors de mes tests, l'EDR a analysé l'interaction anormale du processus Python et a immédiatement "killé" l'action. C'est lui qui me sauve les fesses en entreprise.
Donc même si les systèmes sont vulnérables niveau "kernel", ces "super-antivirus" qui sont aujourd'hui incontournables en entreprise, permettent de limiter l'exposition en attendant le correctif, que je me dépêcherai d'appliquer lors d'une campagne de mise à jour exceptionnelle !
Un EDR n'empêche pas de mettre à jour ses systèmes évidemment ! Mettre à jour ne cause pas des problèmes, ça les règle... normalement !
A propos des clones de Red Hat Enterprise Linux...
Pour les clones (car j'utilise Alma Linux pour le serveur VPS de Linuxtricks), un noyau corrigé est déjà disponible en test. Evidemment, bien que Red Hat n'ait rien proposé, vu qu'Alma Linux est basée sur CentOS Stream, et que ce n'est pas un clone 1:1 de RHEL, ils peuvent intégrer des correctifs et des améliorations "à leur sauce".
J'ai vérifié sur mon propre serveur : après la mise à jour, l'exploit échoue et le système me redemande mon mot de passe.
Toutes les infos ici : https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/
Mais entre le 29 avril et le 1er mai, ça reste toujours trop lent pour fixer le souci !
Conclusion
Même s'il faut un accès sur le serveur pour exploiter la vulnérabilité, elle peut être combinée à une autre vulnérabilité qui permet d'obtenir un shell sur la machine.
Aussi, elle peut être utilisée par quelqu'un qui n'a que les droits utilisateurs sur le système.
L'IA permet d'améliorer la détection des failles, mais rien n'empêche une personne mal-intentionnée de l'utiliser pour en découvrir sans en avertir les mainteneurs du logiciel. Donc l'intelligence artificielle rebat les cartes de la sécurité informatique.
La sécurité est une course permanente : surveillez vos logs et surtout, mettez à jour !
J'espère que ce petit article vous a plu !



