CVE-2026-31431 : 732 octets pour devenir root sur (presque) tous les serveurs Linux

Le 29 avril 2026, un chercheur de l'équipe de recherche de Theori.io a publié les détails d'une vulnérabilité critique du noyau Linux : CVE-2026-31431, surnommée Copy Fail. En résumé : un script Python de 732 octets permet à n'importe quel utilisateur non-privilégié d'obtenir les droits root sur la quasi-totalité des distributions Linux modernes — Ubuntu, Amazon Linux, RHEL, SUSE, et toutes les autres construites sur les noyaux 4.13 ou supérieurs.

Cette faille existe silencieusement dans le code depuis 2017.

Pourquoi cette CVE n'est pas une CVE comme les autres

Trois caractéristiques rendent Copy Fail particulièrement préoccupante pour toute infrastructure cloud, et plus encore pour celles qui font tourner des conteneurs.

Elle est triviale à exploiter. Pas de race condition, pas de timing capricieux, pas de payload compilé spécifique à une version. Le même script fonctionne tel quel sur toutes les distributions testées, sans adaptation. Là où des vulnérabilités historiques comme Dirty Cow ou Dirty Pipe demandaient un certain savoir-faire, Copy Fail s'exécute du premier coup.

Elle est furtive. L'exploitation modifie la version du fichier en mémoire (le page cache du noyau), mais jamais sur le disque. Concrètement, si vos outils de surveillance d'intégrité comparent des empreintes de fichiers stockées sur disque, ils ne verront strictement rien. Le binaire /usr/bin/su reste intact sur le système de fichiers, mais lorsqu'il est exécuté, c'est la version corrompue en mémoire qui s'exécute, avec les privilèges root.

Elle traverse les frontières des conteneurs. Le page cache du noyau est partagé entre tous les processus d'une même machine, conteneurisés ou non. Cela signifie qu'un attaquant ayant compromis un seul pod peut potentiellement remonter jusqu'au nœud Kubernetes, puis impacter l'ensemble des workloads qui s'y exécutent. Xint annonce d'ailleurs un second article consacré spécifiquement à l'évasion de conteneur sur les principales plateformes Kubernetes managées.

Que faire concrètement

Le correctif a été intégré au noyau Linux mainline le 1er avril 2026. Les distributions le déploient progressivement via leurs canaux de mise à jour habituels. Trois actions sont à mener.

1. Inventorier vos versions de noyau. Tout noyau Linux postérieur à 2017 est concerné jusqu'à application du correctif. Sur un cluster Kubernetes, cela signifie auditer chaque nœud, qu'il s'agisse d'une instance EC2, d'un GKE, d'un AKS ou d'une VM auto-gérée.

2. Appliquer une mitigation immédiate. En attendant que votre distribution publie son noyau corrigé, vous pouvez désactiver le module noyau vulnérable. Pour la plupart des charges de travail conteneurisées, cette désactivation est sans impact fonctionnel. Une approche plus alignée avec Kubernetes consiste à bloquer l'appel système concerné via un profil seccomp appliqué à vos workloads.

3. Planifier le redémarrage des nœuds. Une fois le noyau patché disponible, l'application du correctif nécessite un redémarrage. Sur un cluster en production, cela suppose une procédure de drainage et de remise en service nœud par nœud, sans interruption de service côté applicatif.

Le mot de la fin

Copy Fail illustre une réalité que nous observons régulièrement chez nos clients : la sécurité d'un cluster Kubernetes ne se joue pas uniquement au niveau applicatif ou réseau, mais aussi — et surtout — sur la maintenance du socle Linux qui le supporte. Une CVE de cette ampleur exige un inventaire rapide, une mitigation provisoire propre, puis un déploiement coordonné du correctif sur l'ensemble de la flotte.

Si la lecture de cet article vous a fait réaliser que vous ne savez pas exactement quelles versions de noyau tournent sur vos nœuds aujourd'hui, ou comment orchestrer un patching coordonné sans coupure, parlons-en.