Patcher Copy Fail sur Linux : mode d’emploi en quelques minutes

Une faille nommée Copy Fail, divulguée le 29 avril 2026 par les chercheurs de Theori, permet à un utilisateur local de prendre le contrôle root d’un Linux. Cette faille touche tous les noyaux Linux depuis 2017, incluant Ubuntu, Debian, Red Hat, SUSE, AlmaLinux, Fedora, et Arch.

Une vulnérabilité présente depuis neuf ans permet à n’importe quel utilisateur local de prendre le contrôle total d’un système Linux. Si vous possédez un serveur, un Raspberry Pi ou un PC fonctionnant sous Ubuntu, vous êtes concerné.

Un Raspberry Pi utilisé comme NAS, une machine virtuelle hébergeant un site WordPress, un mini-PC sous Debian faisant office de serveur Plex : la situation est préoccupante. Si un individu parvient à ouvrir un terminal sur l’appareil, même avec un compte sans privilèges, il peut rapidement obtenir les droits d’administrateur. Ce « individu » pourrait être un script PHP malveillant, un conteneur Docker mal isolé, ou un invité trop curieux.

Cette faille, nommée Copy Fail, a été révélée le 29 avril 2026 par des chercheurs de Theori. Elle est notée 7,8 sur une échelle de gravité de 10, ce qui indique une nécessité de correction urgente. Elle affecte tous les noyaux Linux depuis 2017, incluant Ubuntu, Debian, Red Hat, SUSE, AlmaLinux, Fedora, Arch, et presque toutes les distributions disponibles sur le marché.

En termes pratiques, un utilisateur sans droits peut modifier quatre octets spécifiques dans la mémoire de l’appareil, ce qui est suffisant pour se faire passer pour l’administrateur. Le programme permettant d’exploiter cette faille ne pèse que 732 octets et est écrit en Python. Ce n’est pas une théorie ; il s’agit d’un script prêt à l’emploi qui fonctionne sur n’importe quelle distribution.

À noter que cette vulnérabilité a été identifiée par un outil d’intelligence artificielle en seulement une heure de scan, alors que des chercheurs humains n’avaient rien détecté depuis près de dix ans.

Il est conseillé de suivre ces étapes selon le type d’appareil que vous possédez :

Pour un PC personnel ou un petit serveur sous Ubuntu ou Debian, la solution est simple : lancez la mise à jour habituelle et redémarrez la machine. Ubuntu a publié un correctif provisoire le 30 avril, désactivant le composant en question en attendant une mise à jour du noyau, et Debian a adopté une approche similaire. Un simple sudo apt update && sudo apt upgrade suivi d’un redémarrage suffira.

Pour un Raspberry Pi ou un NAS, la même procédure s’applique, à condition que la distribution soit toujours maintenue. Si elle ne l’est plus, il est probablement temps de migrer vers une version actuelle.

Pour les serveurs utilisant Red Hat, AlmaLinux ou Rocky, une attention particulière est requise. Une commande circulant sur Internet depuis deux jours pour bloquer manuellement le composant vulnérable ne fonctionnera pas : elle s’exécutera sans erreur, laissant le système vulnérable. Il est donc crucial de procéder directement à la mise à jour officielle ; AlmaLinux a publié son noyau corrigé le 1er mai. Un sudo dnf upgrade et un redémarrage sont suffisants. Pour ceux qui ne peuvent pas redémarrer, des solutions de patch à chaud comme KernelCare existent.

Pour les nœuds Kubernetes et les serveurs d’intégration continue, la priorité est maximale, car ce sont des cibles privilégiées pour ce type d’attaque.

Il est également bon de noter que désactiver le composant vulnérable ne perturbe pas de fonctions essentielles. Ni le chiffrement des disques, ni les VPN, ni SSH, ni les sites HTTPS ne sont affectés. Seules quelques applications très spécifiques utilisant l’accélération matérielle au niveau bas peuvent être impactées, mais cela reste rare en dehors de configurations professionnelles spécifiques.

Android est également protégé grâce à SELinux, qui limite l’accès aux sockets AF_ALG uniquement au processus dumpstate. Ainsi, les politiques restrictives de Google se révèlent bénéfiques cette fois-ci.