CVE-2026-31431 Copy Fail : LPE root quasi-universelle Linux

Les faits

Le 30 avril 2026, les chercheurs de Theori ont publié les détails techniques d'une vulnérabilité critique dans le noyau Linux baptisée « Copy Fail » et identifiée sous l'ID CVE-2026-31431. Bien que le score CVSS officiel soit de 7.8 (High), la faille est considérée par l'ensemble de la communauté sécurité — Sysdig, Wiz, Tenable, Help Net Security et CERT-EU — comme l'une des élévations de privilèges locales les plus impactantes des dix dernières années. Elle permet à n'importe quel utilisateur non privilégié de devenir root en quelques secondes sur la quasi-totalité des distributions Linux livrées depuis 2017, à l'aide d'un exploit déjà public tenant en 732 octets.

La vulnérabilité réside dans le module algif_aead du noyau, qui expose au userspace l'API cryptographique AEAD via la famille de sockets AF_ALG. Plus précisément, c'est le template authencesn qui contient le bug logique. Selon l'analyse publiée par Theori et reprise par Sysdig, une optimisation introduite en 2017 dans le code de copie de buffer entre l'utilisateur et le noyau a brisé l'invariant sur lequel repose la gestion mémoire des opérations AEAD. Le résultat est un primitive d'écriture déterministe et contrôlée : un attaquant local peut écrire 4 octets choisis dans le page cache de n'importe quel fichier lisible par son uid, ce qui suffit à modifier un binaire setuid et obtenir root.

Le caractère exceptionnel de Copy Fail tient à plusieurs propriétés. D'abord, l'exploit est totalement déterministe : pas de race condition, pas de fenêtre temporelle aléatoire, pas de risque de panic kernel. Le PoC publié par Theori utilise uniquement des syscalls standards — socket, setsockopt, splice, sendmsg et recvmsg — disponibles dans toutes les configurations par défaut. Ensuite, le code est trivial à industrialiser : un script Python de 732 octets suffit à éditer un binaire setuid (su, sudo, passwd, mount) pour y injecter une porte dérobée. Enfin, le périmètre est universel : Ubuntu 24.04, RHEL 10.1, SUSE 16, Amazon Linux 2023, AlmaLinux et toute distribution embarquant un noyau 4.14 ou supérieur sont vulnérables, ce qui couvre approximativement 100 % du parc serveur Linux moderne.

La chronologie de divulgation est elle aussi instructive. Le bug a été introduit par un commit d'optimisation en 2017, mais n'a été identifié qu'en mars 2026 par les chercheurs de Theori dans le cadre d'une revue systématique du code crypto du noyau. Le correctif amont, le commit a664bf3d603d, a été poussé dans la branche mainline le 1er avril 2026 ; il consiste à révoquer purement et simplement l'optimisation fautive de 2017. La divulgation publique a eu lieu le 30 avril 2026, accompagnée d'un PoC fonctionnel. AlmaLinux, CloudLinux et Ubuntu ont publié leurs propres patches dans les heures qui ont suivi, mais de nombreux opérateurs accusent encore plusieurs jours de retard, en particulier sur les noyaux personnalisés (kernels HPC, kernels temps-réel, kernels embarqués) ou les distributions à durée de support longue dont le pipeline de backport est plus lent.

L'avis CERT-EU 2026-005 publié le 30 avril qualifie la vulnérabilité de High Vulnerability et appelle les institutions européennes à patcher dans les 72 heures. Tenable, Wiz et Picus Security ont produit des FAQ détaillées le jour même, soulignant que l'absence de prérequis particulier (pas de namespace, pas de capability, pas d'interaction utilisateur) en fait une cible idéale pour les chaînes d'exploitation post-compromission : un attaquant disposant d'un simple shell utilisateur — par exemple via une RCE web app ou un compte SSH compromis — passe root en quelques secondes sans laisser de trace exploitable dans les logs d'audit standards.

Du point de vue technique, ce qui rend Copy Fail particulièrement vicieux est la nature de la primitive : une écriture de 4 octets dans le page cache. Le page cache est partagé entre tous les processus qui ouvrent un même fichier ; modifier le page cache d'un binaire setuid revient donc à modifier toutes les exécutions futures de ce binaire jusqu'à ce que les pages soient évincées. L'exploit Theori cible spécifiquement les binaires setuid root universellement présents (/usr/bin/su ou /usr/bin/passwd), modifie quelques octets de l'instruction de vérification de privilèges, puis exécute le binaire altéré pour obtenir un shell root persistant pour la durée de vie du cache.

Côté détection, la situation est délicate. L'opération malveillante n'écrit pas sur disque (le page cache est en mémoire), ne charge aucun module noyau, ne crée aucun fichier nouveau, et utilise uniquement des syscalls légitimes que des dizaines d'applications normales emploient quotidiennement. Les EDR Linux modernes (Falco, CrowdStrike, SentinelOne) ne disposent pas de signatures spécifiques au moment de la divulgation. La seule télémétrie réellement utile reste l'audit kernel sur les appels à setsockopt avec algorithme AEAD authencesn, ce qui n'est pas activé par défaut sur la majorité des distributions.

Enfin, l'impact dans les environnements conteneurisés est ambigu. Par défaut, Docker et containerd interdisent l'usage de AF_ALG via le filtre seccomp, ce qui bloque l'exploit dans les conteneurs standards. Mais les configurations permissives (containers privilégiés, profils seccomp custom, environnements de calcul scientifique) restent vulnérables. Sur Kubernetes, les pods avec privileged: true ou des SecurityContext permissifs peuvent servir de tremplin pour échapper au conteneur, atteindre l'hôte et compromettre tout le cluster.

Impact et exposition

L'exposition de Copy Fail est massive. Selon les estimations de Wiz et Sysdig, plus de 95 % des serveurs Linux en production dans le monde tournent sur un noyau vulnérable au moment de la divulgation. Les services cloud les plus impactés sont AWS EC2 (Amazon Linux 2023, Ubuntu), Azure Linux VM, Google Compute Engine, ainsi que toutes les images de conteneurs basées sur des distributions standards. Les workloads Kubernetes auto-managés (kops, kubeadm) sont particulièrement à risque lorsque les nodes ne reçoivent pas leurs mises à jour kernel automatiquement.

Aucune exploitation in-the-wild n'est confirmée à la date de la divulgation, mais les chercheurs anticipent une intégration rapide du PoC dans les frameworks de post-exploitation (Metasploit, Sliver, Cobalt Strike) et les kits ransomware. Les attaquants spécialisés dans les supply-chain compromises et les phases de privilège escalation post-RCE ont désormais un outil universel à leur disposition.

L'exposition est aggravée par la longue durée de vie de certaines distributions. RHEL 8, encore largement déployé en entreprise jusqu'en 2029, doit recevoir un backport via Red Hat Enterprise Linux ELS ; les organisations sur des kernels custom (clusters HPC, appliances industrielles, équipements télécom) doivent recompiler manuellement avec le commit a664bf3d603d. Le risque est particulièrement élevé pour les opérateurs d'importance vitale (OIV) et les opérateurs de services essentiels (OSE) au sens de la directive NIS2.

Pour les fournisseurs de plateformes multi-tenants (hébergeurs mutualisés, plateformes CI/CD shared, environnements de developement partagés), Copy Fail représente un risque systémique : un seul utilisateur malveillant suffit à compromettre l'ensemble du nœud et à pivoter vers les workloads voisins. Cloud Linux a d'ailleurs publié son patch en moins de 24 heures, conscient que sa base de clients (hébergeurs cPanel/WHM mutualisés) est en première ligne.

Recommandations immédiates

• Appliquer la mise à jour kernel — advisory : Ubuntu USN, AlmaLinux ALSA, CloudLinux KernelCare, RHEL RHSA, SUSE SUSE-SU, Amazon Linux ALAS du 30 avril ou 1er mai 2026 (sans lien externe).
• Si la mise à jour ne peut être déployée immédiatement, blacklister le module algif_aead en ajoutant install algif_aead /bin/false dans /etc/modprobe.d/disable-algif_aead.conf puis exécuter rmmod algif_aead.
• Vérifier que les profils seccomp Docker, containerd et Kubernetes bloquent bien la famille de sockets AF_ALG ; refuser les pods en mode privileged: true sur tous les clusters de production.
• Activer l'audit kernel sur les appels à setsockopt ciblant l'algorithme AEAD authencesn et envoyer ces événements vers le SIEM pour détection rétroactive.
• Lancer une chasse sur les binaires setuid système (find / -perm -4000 -type f) et comparer leurs hashes avec les valeurs de référence du paquet d'origine pour repérer une éventuelle altération via page cache.