Une nouvelle vulnérabilité d’élévation de privilèges locale (LPE) vient de secouer l’écosystème Linux. Baptisée Copy Fail et référencée CVE-2026-31431, elle a été divulguée publiquement le 29 avril 2026 par les chercheurs de Xint Code (filiale de Theori). Sa particularité : un exploit fonctionnel tient en 732 octets de Python, fonctionne sans modification sur toutes les distributions majeures, et reste fiable à 100 %.

Une faille logique, pas une condition de course

Contrairement à la majorité des LPE Linux, qui reposent sur des fenêtres de race condition étroites ou sur des offsets noyau spécifiques à chaque version, Copy Fail est une erreur logique pure et linéaire dans le code. Pas de timing à respecter, pas d’adaptation par kernel : le bug se déclenche de la même manière partout.

L’exploitation s’appuie sur une chaîne précise :

une erreur logique dans la primitive authencesn ;
un détournement de l’interface crypto utilisateur AF_ALG ;
l’utilisation de splice() pour aboutir à une écriture de 4 octets dans le page cache.

Ces 4 octets, soigneusement placés, suffisent à modifier en mémoire un binaire setuid (par défaut /usr/bin/su) et à transformer un utilisateur ordinaire en root. La modification n’est pas persistante après redémarrage, mais le shell root, lui, est bien réel.

Toutes les distributions Linux depuis 2017 sont vulnérables

Si votre noyau a été compilé entre 2017 et le correctif diffusé fin avril 2026, vous êtes concerné. L’API crypto noyau AF_ALG est activée par défaut dans la quasi-totalité des configurations, ce qui expose la faille out of the box.

Les chercheurs ont vérifié directement les distributions suivantes :

Distribution	Noyau testé
Ubuntu 24.04 LTS	`6.17.0-1007-aws`
Amazon Linux 2023	`6.18.8-9.213.amzn2023`
RHEL 10.1	`6.12.0-124.45.1.el10_1`
SUSE 16	`6.12.0-160000.9-default`

Debian, Arch, Fedora, Rocky, Alma, Oracle Linux et l’écosystème embarqué se comportent de manière identique dès lors qu’ils tournent sur un noyau vulnérable.

Qui doit patcher en priorité ?

Tous les environnements ne courent pas le même risque. Voici les profils les plus exposés :

Hôtes Linux multi-tenants (priorité haute) : machines de développement partagées, shell-as-a-service, bastions, serveurs de build. N’importe quel utilisateur peut devenir root.
Clusters Kubernetes et conteneurs (priorité haute) : le page cache étant partagé avec l’hôte, un pod malveillant peut compromettre le nœud et franchir les frontières de tenants.
Runners CI/CD et build farms (priorité haute) : runners auto-hébergés GitHub Actions, GitLab, agents Jenkins. Une simple Pull Request peut prendre le contrôle du runner.
SaaS exécutant du code utilisateur (priorité haute) : hôtes de notebooks, sandboxes d’agents IA, fonctions serverless, conteneurs fournis par les clients.
Serveurs Linux mono-tenants (priorité moyenne) : LPE interne, à enchaîner avec une RCE web ou un vol d’identifiants.
Postes de travail mono-utilisateur (priorité plus faible) : le bug ne donne pas d’accès distant, mais toute exécution de code local devient une élévation root.

Mitigation : patcher ou désactiver algif_aead

La correction officielle est intégrée au commit mainline a664bf3d603d, qui supprime l’optimisation in-place introduite en 2017 dans algif_aead. La plupart des grandes distributions diffusent déjà des paquets noyau corrigés.

En attendant le patch, il est recommandé de désactiver le module algif_aead :

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead

Bonne nouvelle : pour la quasi-totalité des systèmes, rien de fonctionnel n’est cassé. Selon Xint Code, ne sont pas affectés : dm-crypt / LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS dans leur configuration par défaut, SSH ou encore le keyring noyau, qui utilisent tous directement l’API crypto interne du kernel sans passer par AF_ALG.

Peuvent en revanche être impactés : OpenSSL avec le moteur afalg explicitement activé, certains chemins crypto offload embarqués, ou les applications qui ouvrent directement des sockets aead / skcipher / hash. Une vérification rapide avec lsof | grep AF_ALG ou ss -xa permet de lever le doute.

Pour les workloads non fiables (conteneurs, sandboxes, CI), il est conseillé de bloquer la création de sockets AF_ALG via une politique seccomp, patch ou pas.

Une faille trouvée par une IA en une heure

Le point peut-être le plus marquant de cette divulgation : Copy Fail a été identifiée par Xint Code, un outil d’audit de code automatisé piloté par IA, au cours d’environ une heure de scan sur le sous-système crypto/ du noyau Linux. La même campagne a remonté d’autres failles de haute sévérité actuellement en cours de divulgation coordonnée.

Theori revendique également plusieurs faits d’armes notables : sweep de la catégorie bases de données (Redis, PostgreSQL, MariaDB) à ZeroDay Cloud, finaliste DARPA AIxCC, et neuf victoires au DEF CON CTF.

Chronologie de la divulgation

23 mars 2026 — Signalement à l’équipe sécurité du noyau Linux
24 mars 2026 — Accusé de réception
25 mars 2026 — Patches proposés et relus
1er avril 2026 — Correctif intégré au mainline
22 avril 2026 — Attribution du CVE-2026-31431
29 avril 2026 — Divulgation publique

À retenir

Copy Fail illustre deux tendances de fond : la persistance, pendant près d’une décennie, de bugs logiques simples dans des composants critiques du noyau, et la montée en puissance des outils d’audit IA capables de les exhumer en quelques heures de scan. Pour les administrateurs système et les équipes sécurité, la consigne est claire : mettre à jour le noyau sans tarder, surveiller les environnements partagés, et envisager de durcir les politiques seccomp pour les workloads non fiables.