Depuis des années, une idée confortable est répétée : Linux est sécurisé, stable et idéal pour les serveurs qui peuvent fonctionner des mois sans intervention. La première partie reste vraie dans de nombreux domaines. Linux constitue une base solide, vérifiable, avec une communauté de sécurité énorme derrière. En revanche, la seconde, devenue dangereuse, doit être revue. Un serveur Linux ne peut pas être installé, durci une seule fois, puis abandonné jusqu’au prochain changement de matériel.
Les dernières semaines ont laissé une série d’alertes qui devraient faire réagir tout administrateur : Copy Fail, Dirty Frag, Fragnesia et ssh-keysign-pwn. Il ne s’agit pas de failles mineures ou de vulnérabilités théoriques enfouies dans un sous-système exotique dont personne ne se sert. Plusieurs d’entre elles permettent une escalade de privilèges locale jusqu’à root, d’autres exposent des secrets de root comme des clés SSH ou le fichier /etc/shadow, et certaines disposent de démonstrations publiques. Dans les environnements cloud, serveurs partagés, machines de développement, bastions SSH, clusters Kubernetes ou hébergement multi-utilisateur, une faille locale peut devenir un problème infrastructurel.
Copy Fail, identifié comme CVE-2026-31431, a été dévoilée le 29 avril 2026 et concerne le module algif_aead du noyau, l’interface AEAD de l’API cryptographique utilisateur AF_ALG. CERT-EU la décrit comme une escalade de privilèges locale avec CVSS 7.8, touchant les distributions Linux principales avec des kernels compilés depuis 2017. La technique permet, en combinant AF_ALG avec splice(), une écriture contrôlée dans des pages soutenues par la cache mémoire, en s’attaquant notamment à des binaires setuid comme /usr/bin/su.
Microsoft a également alerté sur son impact dans les charges cloud Linux et clusters Kubernetes, signalant qu’un PoC fonctionnel augmentait le risque d’exploitation. La même publication mentionne que CISA a ajouté CVE-2026-31431 à son catalogue de vulnérabilités exploitées, renforçant la priorité opérationnelle pour les organisations n’ayant pas encore effectué la mise à jour.
Une succession de failles qui renferme une même leçon
Dirty Frag est apparu peu après. CloudLinux le présente comme une seconde escalade de privilèges locaux dans le même cadre large que Copy Fail, cette fois sur des chemins de déchiffrement in-place de esp4, esp6 et rxrpc. La vulnérabilité, associée à CVE-2026-43284 et CVE-2026-43500, permet à des processus sans privilèges de conserver des références à des données pouvant aboutir à une primitive d’écriture dans la cache mémoire. En pratique, un PoC public pouvait transformer un compte local sans privilèges en root.
INCIBE-CERT a publié une mitigation temporaire pour Dirty Frag, bloquant le chargement des modules esp4, esp6 et rxrpc, désinstallant ces modules si présents, et nettoyant la cache mémoire. Ce n’est pas une correction définitive, mais une défense utile en attendant le déploiement d’un kernel corrigé, à condition que le serveur ne dépende pas d’IPsec ou de RxRPC.
Suit Fragnesia, CVE-2026-46300, une vulnérabilité distincte mais appartenant à la même famille XFRM/ESP. CloudLinux la décrit comme la troisième escalade locale de privilèges en trois semaines nécessitant un patch et un redémarrage, après Copy Fail et Dirty Frag. La mitigation immédiate consiste à bloquer les modules concernés jusqu’à l’application d’un kernel corrigé.
La quatrième alerte récente, ssh-keysign-pwn, change quelque peu de nature. CVE-2026-46333 ne constitue pas une escalade directe vers root, mais une fuite d’informations critiques via la logique d’accès de ptrace. Selon AlmaLinux, Qualys a signalé cette faille à [email protected], Linus Torvalds a intégré la correction le 14 mai 2026, et peu après, des exploits fonctionnels ont été publiés permettant de lire des clés SSH privées via ssh-keysign et le fichier /etc/shadow via chage -l.
CloudLinux résume clairement : un utilisateur local sans privilèges sur un serveur affecté peut lire des secrets propriété de root sans pour autant obtenir la racine. Ce genre d’information devrait suffire à inciter toute équipe système à agir en urgence. Une clé privée SSH ou le hash de /etc/shadow peut ouvrir la voie à des usurpations, crack offline, mouvements latéraux et compromissions ultérieures.
Le problème ne tient pas à Linux, mais à notre façon de l’entretenir
Il serait erroné de conclure que Linux est dangereux à cause de cette suite de failles. Le noyau est une pièce immense, très complexe, et utilisé dans des contextes très variés : ordinateurs portables, mobiles, routeurs, serveurs cloud, supercalculateurs, conteneurs, systèmes embarqués, stockage, réseaux et virtualisation. Ce que révèlent ces cas, ce n’est pas une faiblesse propre à Linux face à d’autres systèmes, mais la nécessité de traiter le maintien du noyau comme une tâche continue et prioritaire.
Le premier changement de mentalité consiste à reconnaître que les vulnérabilités locales comptent. Beaucoup d’organisations considèrent ces failles comme secondaires, pensant que l’attaquant doit déjà être à l’intérieur. En 2026, cette vision est insuffisante. Un attaquant peut arriver avec un compte limité, un conteneur mal isolé, un runner CI/CD, un site web vulnérable, un compte SFTP ou un accès temporaire fourni par un prestataire. Si, à partir de là, il peut atteindre root ou exfiltrer des secrets, le périmètre n’est plus une garantie.
Le deuxième changement consiste à accepter que redémarrer les serveurs fait partie intégrante de la sécurité. Pendant longtemps, la disponibilité a été valorisée comme si un serveur en ligne depuis 800 jours était un signe d’excellence. Aujourd’hui, cela peut indiquer qu’il est abandonné. Un temps de fonctionnement excessif sur des systèmes exposés témoigne souvent de kernels obsolètes, modules non corrigés, vulnérabilités accumulées. La disponibilité ne s’obtient pas en évitant systématiquement les redémarrages, mais en concevant des services avec Redondance, pour pouvoir appliquer des patchs en toute sérénité.
Le troisième changement consiste à distinguer mise à jour des paquets et mise à jour du noyau en fonctionnement. Sur Linux, il est fréquent d’appliquer des correctifs logiciels sans redémarrer, alors que le kernel vulnérable reste en mémoire jusqu’au prochain reboot. Après une mise à jour du noyau, il faut vérifier la version en cours avec uname -r, s’assurer qu’un redémarrage n’est pas en attente, et préparer le serveur pour minimiser la fenêtre d’exposition. Dans les distributions professionnelles, des outils comme needrestart, dnf needs-restarting, reboot-required ou les alertes du fournisseur aident, mais une politique claire reste indispensable.
Mesures concrètes pour garder Linux à l’abri de problèmes graves
La première étape consiste à réaliser un inventaire précis. On ne peut protéger ce que l’on ne connaît pas. Il faut recenser la distribution, la version, le kernel en cours, le kernel installé, la fonction du serveur, le niveau d’exposition locale, l’utilisation de conteneurs, les modules chargés et la criticité du service. Lorsqu’une faille comme Copy Fail ou Dirty Frag apparaît, l’équipe doit pouvoir répondre en quelques minutes à une question essentielle : quels sont les systèmes concernés ?
La deuxième étape est l’automatisation des alertes de sécurité. Le suivi des vulnérabilités comme Debian Security Tracker, Ubuntu Security Notices, la base de données CVE de Red Hat, les avis de sécurité AlmaLinux, Rocky Linux, SUSE, CISA KEV, CERT-EU, INCIBE-CERT et ceux des fournisseurs tels que CloudLinux doit être intégré dans le suivi. Il n’est pas nécessaire de tout lire manuellement, mais il faut recevoir des alertes filtrées par distribution et criticité.
La troisième étape est définir des fenêtres de mise à jour concrètes. Sur des serveurs non critiques, des mises à jour automatiques et des redémarrages planifiés peuvent suffire. En production sensible, il faut des groupes, des équilibreurs de charge, des nœuds redondants et un maintenance progressive. L’objectif n’est pas d’appliquer des patchs “quand cela est possible”, mais de réserver du temps pour pouvoir patcher avant qu’une vulnérabilité publique ne devienne un incident.
La quatrième étape consiste à considérer le live patching. Ce n’est pas une solution miracle, mais cela peut réduire considérablement le risque dans le cas d’une vulnérabilité critique du kernel nécessitant une réaction urgente, sans attendre un redémarrage. CloudLinux mentionne KernelCare comme une option pour appliquer des correctifs de sécurité en continu. D’autres distributions offrent des alternatives comme kpatch, kGraft, Canonical Livepatch ou des solutions commerciales. La clé est de vérifier que le correctif en live patch couvre précisément le CVE concerné, sans quoi il ne faut pas s’y fier aveuglément.
La cinquième étape est d’appliquer des mitigations temporaires avec discernement. Pour Dirty Frag et Fragnesia, bloquer esp4, esp6 et rxrpc peut être pertinent sur certains serveurs web ou machines ne utilisant pas IPsec ou AFS, mais cela peut perturber des tunnels strongSwan, Libreswan, ou autres usages légitimes d’IPsec. Pour ssh-keysign-pwn, renforcer ptrace, limiter les user namespaces non privilégiés ou retirer temporairement le bit SUID de certains binaires peut réduire la surface d’attaque, tout en pouvant impacter la débogage ou certains environnements containerisés. Ces mitigations doivent toujours préparer le terrain pour le correctif définitif, et non en remplacer l’application.
La sixième étape consiste à réduire au minimum les utilisateurs locaux non indispensables. Si un serveur n’a pas besoin d’accès shell pour ses clients, il ne doit pas en avoir. Si un runner CI exécute du code non trustworthy, il doit être isolé et facilement remplaçable. Si un panneau d’hébergement permet d’exécuter des processus, leur confinement doit être adapté aux risques. Plus il est facile d’obtenir un accès local, plus une vulnérabilité devient critique.
La septième étape est la rotation des secrets lorsque la faille le justifie. Sur ssh-keysign-pwn, corriger le kernel évite l’exploitation future, mais ne modifie pas automatiquement une clé SSH potentiellement compromises. Sur des hôtes exposés ou multi-utilisateurs, la rotation des clés SSH du système, la révision de /etc/shadow, le changement des mots de passe locaux et la vérification des empreintes doivent faire partie du plan d’action.
Assurer la sécurité de Linux ne signifie pas vivre en état d’alerte permanente. Cela veut dire mettre en place des procédures avant que ne survienne l’incident : inventaire précis, alertes automatisées, politiques de patching, redémarrages planifiés, live patching, mitigations documentées, et capacité à répondre rapidement. Les vulnérabilités récentes ne sont pas un signe pour se méfier de Linux, mais une invitation à le gérer comme une infrastructure critique, en constante évolution et qui ne pardonne pas l’abandon.
Questions fréquentes
Ces failles concernent-elles tous les serveurs Linux ?
Pas tous de la même manière. Copy Fail, Dirty Frag, Fragnesia et ssh-keysign-pwn impactent des distributions très répandues. La façon la plus fiable de le savoir est de vérifier l’avis du fournisseur et la version du kernel en cours d’utilisation.
Une vulnérabilité locale est-elle moins urgente qu’une vulnérabilité distante ?
Pas toujours. Sur des serveurs partagés, dans le cloud, en containers, en CI/CD ou avec des utilisateurs non fiables, une faille locale peut conduire à l’obtention de root ou à une fuite de secrets.
Est-ce qu’il suffit de faire apt update ou dnf upgrade ?
Non. En cas de faille kernel, il faut appliquer le kernel corrigé et redémarrer, sauf si un live patch a été confirmé comme efficace pour cette vulnérabilité. Après la mise à jour, vérifier avec uname -r.
Que doit faire une entreprise pour ne pas toujours être en retard ?
Maintenir un inventaire précis, s’abonner aux alertes de sécurité, automatiser les patchs quand possible, concevoir une haute disponibilité pour pouvoir redémarrer en toute sécurité, utiliser le live patching sur les systèmes critiques, et revoir les accès locaux superflus.
