Lire les fichiers root sans privilège : ce que la CVE-2026-46333 révèle de neuf ans d’angle mort dans le noyau Linux
Une race window dans le contrôle d’accès ptrace du noyau Linux permet, via pidfd_getfd(2), de voler les descripteurs de fichiers ouverts par un binaire SUID root sur le point de se terminer. Deux exploits publics exfiltrent les clés privées hôte SSH et le contenu de /etc/shadow. Régression de 2017, pattern signalé par Jann Horn en 2020, corrigé le 14 mai 2026.
Le 14 mai 2026, Qualys a signalé une vulnérabilité du noyau Linux. Le même jour, Linus Torvalds a poussé le correctif. Quelques heures plus tard, le chercheur _SiCk publiait deux exploits fonctionnels permettant à n’importe quel utilisateur local de lire les clés privées hôte SSH et le hash root de /etc/shadow. Une chaîne complète, du signalement au PoC, en moins de vingt-quatre heures, sur un défaut qui aura mis neuf ans à être corrigé après avoir été flagué publiquement par Jann Horn cinq ans plus tôt.
Une chaîne complète en vingt-quatre heures
Le 14 mai 2026, l’équipe de recherche Qualys a signalé à security@kernel.org une vulnérabilité du noyau Linux affectant la fonction __ptrace_may_access(). La faille a reçu l’identifiant CVE-2026-46333. Elle permet à un utilisateur local non privilégié de récupérer des descripteurs de fichiers ouverts par un processus SUID root sur le point de se terminer, et par ce biais de lire des fichiers normalement réservés à root (1)(2).
Le même jour, Linus Torvalds a poussé le correctif amont sous le commit 31e62c2ebbfd, intitulé ptrace: slightly saner ‘get_dumpable()’ logic (3). Quelques heures après la publication du commit correctif, le chercheur opérant sous le pseudonyme _SiCk (compte GitHub 0xdeadbeefnetwork) a publié sur GitHub un dépôt nommé ssh-keysign-pwn contenant deux exploits fonctionnels. Le premier, sshkeysign_pwn, exfiltre les clés privées hôte SSH stockées dans /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key. Le second, chage_pwn, exfiltre le contenu de /etc/shadow, permettant le crack offline du hash root (4).
À la date de rédaction, l’ensemble des noyaux Linux stables référencés sur kernel.org au 14 mai 2026 sont vulnérables. La régression sous-jacente a été introduite en 2017 par le commit bfedb589 dans la branche v4.10-rc1. Les noyaux antérieurs à cette branche, en particulier les 3.10 utilisés par RHEL 7 et CloudLinux 7, ne sont pas affectés.
Aucune exploitation in-the-wild n’a été rapportée à ce jour, mais deux PoC publics fonctionnels sont disponibles depuis le 14 mai 2026. Le bulletin officiel de Qualys, qui constituera la référence technique attendue de cette équipe sur la lignée des LPE PwnKit, Sequoia et Looney Tunables, n’est pas encore publié au moment de la rédaction.
La semaine précédente, le 7 mai 2026, le même chercheur _SiCk avait publié Copy Fail 2: Electric Boogaloo, un n-day construit à partir du commit fix amont de Dirty Frag (CVE-2026-43284), poussé publiquement sur netdev/net.git deux jours avant la date de divulgation coordonnée prévue. Le pattern de production se confirme : tout commit fix amont publiquement visible est désormais traité comme une fenêtre d’exposition active jusqu’à la propagation des correctifs binaires sur les distributions.
Anatomie du défaut : le saut du contrôle dumpable
La fonction __ptrace_may_access() est la gatekeeper noyau qui détermine si un processus peut inspecter l’état d’un autre processus. Elle est invoquée en amont de la majorité des mécanismes d’introspection : ptrace, accès à /proc/$pid/mem, et plus particulièrement pidfd_getfd(2), syscall introduite en Linux 5.6 pour cloner un descripteur de fichier détenu par un autre processus.
Cette fonction effectue plusieurs contrôles. L’un d’eux, le contrôle dumpable, vérifie si le processus cible autorise l’extraction de son image mémoire. Le flag dumpable a été conçu, à l’origine, comme une propriété de l’image mémoire d’un processus. Un binaire SUID qui ouvre un fichier réservé à root puis abandonne ses privilèges positionne typiquement sa propriété dumpable à zéro après l’élévation, afin d’empêcher un dump mémoire d’exposer des secrets.
Le défaut introduit en 2017 réside dans une optimisation logique apparemment inoffensive : lorsque la cible n’a plus de descripteur mémoire (task->mm == NULL), __ptrace_may_access() saute purement et simplement le contrôle dumpable. La justification originelle est que les threads kernel et les processus en cours de sortie n’ont pas d’image mémoire à protéger, et que le contrôle n’a donc pas de sens pour ces cibles. Linus Torvalds résume ainsi le défaut dans le message du commit correctif :
Le second élément du défaut tient à la séquence d’exécution de do_exit() dans le noyau Linux. Cette fonction, qui pilote la terminaison d’un processus, libère les ressources dans un ordre précis : exit_mm() est appelée avant exit_files(). Il existe donc, dans la vie de chaque processus se terminant normalement, une fenêtre temporelle pendant laquelle le descripteur mémoire a déjà été libéré (task->mm == NULL) mais où les descripteurs de fichiers ouverts par le processus n’ont pas encore été fermés (5)(6).
Pendant cette fenêtre, le contrôle dumpable est sauté, et tout processus disposant du même UID que la cible peut appeler pidfd_getfd(2) pour copier un descripteur de fichier détenu par la cible. La race est de type TOCTOU. La fenêtre temporelle est courte mais largement suffisante pour qu’une exploitation pratique fonctionne. Le PoC publié par _SiCk atteint un taux de succès stable sur 100 à 2 000 spawns du binaire cible, soit quelques secondes à quelques minutes sur une machine standard.
Deux primitives publiées, une classe d’attaque large
Le dépôt ssh-keysign-pwn fournit deux binaires d’exploitation indépendants, chacun ciblant un binaire SUID root classique d’une distribution Linux standard (4). Les deux primitives partagent la même mécanique noyau, mais visent des actifs sensibles différents.
La primitive sshkeysign_pwn
La première primitive cible ssh-keysign, binaire helper d’OpenSSH installé par défaut sur la majorité des distributions et utilisé dans le cadre de l’authentification host-based. Le binaire est SUID root afin de pouvoir lire les clés privées hôte de la machine, stockées en mode 0600 dans /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key et /etc/ssh/ssh_host_rsa_key.
Le code source de ssh-keysign.c présente, depuis 2002, une séquence d’exécution particulière. Le binaire ouvre les fichiers de clés privées hôte avant d’appeler permanently_set_uid(), puis vérifie si la directive EnableSSHKeysign est positionnée dans sshd_config. Si elle ne l’est pas, comportement par défaut sur la majorité des installations modernes, le binaire abandonne immédiatement, avec les descripteurs de fichiers vers les clés privées encore ouverts. Le processus entre alors en phase de terminaison, déclenche do_exit(), et expose pendant la fenêtre mm == NULL les descripteurs vers les clés hôte.
Une fois ces descripteurs récupérés via pidfd_getfd(2), l’attaquant peut lire intégralement le contenu des clés privées sur la sortie standard. Les implications opérationnelles sont significatives. La possession des clés privées hôte d’un serveur SSH permet l’impersonation complète de ce serveur dans des scénarios d’attaque man-in-the-middle, le déchiffrement de captures réseau SSH lorsqu’aucun mécanisme de forward secrecy n’a été utilisé, et plus largement la rupture de la chaîne de confiance reposant sur la fingerprint de l’hôte.
La primitive chage_pwn
La seconde primitive cible chage, utilitaire shadow-utils permettant à un utilisateur de consulter ou modifier ses propres informations de vieillissement de mot de passe. Le binaire est SUID root afin de pouvoir ouvrir /etc/shadow en lecture.
Lorsque chage -l <user> est invoqué, le binaire appelle spw_open(O_RDONLY) pour ouvrir /etc/shadow, puis exécute setreuid(ruid, ruid) pour abandonner ses privilèges. Le double passage du même argument (le real UID de l’utilisateur appelant) entraîne un drop complet : uid = euid = suid = ruid. Le descripteur vers /etc/shadow reste ouvert pendant que le binaire prépare sa sortie. La race window est exploitée de la même manière que pour ssh-keysign, et l’attaquant récupère le contenu intégral de /etc/shadow. L’exploitation peut être complétée hors ligne par une attaque par dictionnaire ou par force brute sur le hash root.
Les deux primitives illustrent une classe d’attaque commune. Tout binaire SUID root qui ouvre un fichier sensible avant d’abandonner ses privilèges, et dont la fin de processus déclenche un passage par la fenêtre mm == NULL avec des descripteurs encore ouverts, devient exploitable via CVE-2026-46333. Cette classe n’est pas limitée à ssh-keysign et chage. Les candidats raisonnables à des primitives supplémentaires incluent su, sudo, pkexec, passwd, gpasswd et newgrp, dont les chemins d’exécution comportent des étapes d’ouverture de fichiers d’authentification avant drop. L’apparition de primitives d’exploitation supplémentaires dans les jours suivants la publication du correctif est à anticiper.
Périmètre d’impact et cas particulier des kernels longue durée
Tous les noyaux Linux stables au 14 mai 2026 sont affectés, c’est-à-dire l’ensemble des branches dérivant des mainline postérieures à v4.10-rc1 (janvier 2017). La régression a été introduite par le commit bfedb589, dont la finalité initiale était indépendante du chemin ptrace_may_access(). Les noyaux 3.10 maintenus dans RHEL 7 et ses dérivés ne contiennent pas la régression et ne sont pas exploitables par cette voie.
Les distributions suivantes ont été testées avec succès par les exploits publics : Debian 13, Ubuntu 22.04 LTS, 24.04 LTS et 26.04 LTS, Arch Linux, CentOS Stream 9, Raspberry Pi OS Bookworm (kernel 6.12.75) (4)(7). L’extrapolation à l’ensemble des distributions exécutant un noyau postérieur à v4.10 est immédiate. Fedora, openSUSE, AlmaLinux, Rocky Linux, RHEL 8, RHEL 9, RHEL 10, Oracle Linux et leurs dérivés sont à considérer comme affectés en l’absence d’indication contraire dans leurs bulletins respectifs.
L’avis publié par CloudLinux apporte une distinction utile entre exposition au défaut sous-jacent et exploitabilité par le PoC public actuel (8). Cette distinction est généralisable à d’autres familles de kernels longue durée et mérite d’être conservée dans les évaluations de risque.
Les machines CloudLinux 7h et CloudLinux 8 ne doivent pas être considérées comme définitivement protégées au seul motif que pidfd_getfd(2) est absente de leur ABI. La race noyau sous-jacente est présente, et une exploitation alternative via d’autres voies d’accès aux descripteurs de fichiers d’un processus en exit reste plausible. La disparition d’une syscall n’élimine pas la classe de vulnérabilité.
Les environnements opérationnels particulièrement exposés incluent les hébergeurs mutualisés où des utilisateurs locaux non privilégiés disposent d’accès shell sur des machines partageant le même noyau, les bastions et serveurs SSH multi-utilisateurs où la compromission des clés hôte aurait un impact systémique sur la chaîne de confiance, les environnements de continuous integration où des workloads tiers s’exécutent avec un UID local sur des runners persistants, et les conteneurs Kubernetes sans seccomp restrictif où pidfd_getfd(2) n’est pas bloquée.
Neuf ans de régression, cinq ans après le signal Jann Horn
L’écart temporel le plus instructif n’est pas celui de neuf ans entre l’introduction du commit fautif et sa correction, mais celui de plus de cinq ans entre le signalement public du pattern d’exploitation et la publication du correctif effectif.
Le 16 octobre 2020, Jann Horn, chercheur de Google Project Zero, publie sur la liste lore.kernel.org un patch proposant de corriger un pattern de vol de descripteurs de fichiers reposant précisément sur le saut de dumpable en cas de mm == NULL (9). La proposition décrit la mécanique exacte exploitée six ans plus tard par les PoC publics de _SiCk. Le patch n’est pas intégré. Aucun avis public ne suit. Le défaut reste latent dans le noyau pour cinq ans supplémentaires.
Ce délai pose une question structurelle qui dépasse la seule CVE-2026-46333. Les listes lore.kernel.org et les propositions de patches publiques constituent un fonds documentaire considérable, dans lequel des défauts sont régulièrement signalés sans qu’un suivi systématique de leur correction effective ne soit assuré. La capacité d’audit assistée par intelligence artificielle, désormais accessible à un coût marginal faible, transforme ce fonds en un terrain de chasse pour la redécouverte de défauts dormants. L’écart entre le signalement Jann Horn et le correctif Qualys illustre concrètement ce mécanisme.
L’hypothèse formulée par Sysdig à propos de Dirty Frag, selon laquelle la durée écoulée entre l’introduction des défauts et leur découverte récente impliquerait un appui d’outils d’analyse assistée par IA, est cohérente avec le cas ssh-keysign-pwn. L’analyse Mozilla publiée la même semaine confirme que cet appui est désormais industrialisé du côté des éditeurs, avec 271 vulnérabilités Firefox identifiées sur deux mois par Anthropic Mythos. L’écart de capacité entre acteurs disposant d’infrastructures d’audit assistées par IA et acteurs n’en disposant pas devient un facteur structurant de la dynamique des découvertes (10).
Pour les équipes CTI, ce signal mérite d’être intégré aux exercices de prospective. La probabilité de redécouvertes industrielles de défauts noyau historiques sur les douze prochains mois est élevée. La famille Dirty Frag, Fragnesia, Copy Fail et désormais ssh-keysign-pwn forme un faisceau dont la concentration temporelle en mai 2026 n’est probablement pas un accident statistique mais le marqueur d’une transition d’échelle dans la capacité d’audit du noyau Linux.
Mitigations et état du correctif
L’application du correctif amont 31e62c2ebbfd constitue la seule mitigation complète et fiable (3). Sa propagation s’effectue via les canaux suivants : mainline sur l’arbre Linus Torvalds depuis le 14 mai 2026, AlmaLinux 9 et 10 dans les dépôts testing au 15 mai 2026 avec promotion vers production prévue à court terme (11), CloudLinux 9 et 10 utilisant le noyau AlmaLinux et suivant le même calendrier, CloudLinux 8 LTS via son canal LTS dédié, et les distributions Debian et Ubuntu en cours de propagation. Pour les environnements CloudLinux et AlmaLinux, KernelCare prépare un livepatch permettant l’application du correctif sans redémarrage.
Mitigation immédiate par Yama ptrace_scope
Qualys a publié sur la liste oss-security une mitigation par durcissement du module Yama, en attendant le déploiement des kernels patchés (12). La mitigation consiste à positionner la sysctl kernel.yama.ptrace_scope à une valeur restrictive. La valeur 3 désactive entièrement l’attachement ptrace. La valeur 2 restreint l’attachement aux administrateurs. Les deux valeurs bloquent les PoC publics actuels, qui s’appuient sur le contrôle d’accès de pidfd_getfd(2) transitant par __ptrace_may_access().
Effet de bord à anticiper : la valeur 3 brise les outils de débogage locaux (gdb attach, strace -p, profilers en mode attach). Pour les machines de développement, la valeur 2 constitue un compromis raisonnable. Pour les serveurs de production sans usage légitime de ptrace, la valeur 3 est recommandée.
La mitigation Yama est explicitement présentée par Qualys comme un workaround et non comme un correctif. D’autres voies d’exploitation du même défaut sous-jacent sont théoriquement possibles, et n’ont pas nécessairement été couvertes par cette mesure. L’application du correctif noyau reste la cible finale, et le maintien de la mitigation Yama doit être considéré comme temporaire dans l’attente du déploiement complet des kernels patchés.
Défense en profondeur via seccomp
Pour les environnements conteneurisés, un profil seccomp bloquant explicitement la syscall pidfd_getfd(2) neutralise les PoC publics. Cette mesure est à considérer comme une défense en profondeur, et non comme une alternative au correctif noyau. Pour Kubernetes, le profil seccomp RuntimeDefault bloque par défaut pidfd_getfd(2) sur la majorité des runtimes modernes. Les pods déployés sans profil seccomp explicite, ou avec un profil Unconfined, restent exposés. Une vérification de la couverture seccomp à l’échelle du cluster est recommandée en amont du déploiement du correctif noyau.
Audit et durcissement des binaires SUID
En complément des mitigations directes, un audit du parc des binaires SUID root permet d’identifier les binaires de la classe vulnérable. Pour ssh-keysign spécifiquement, le bit SUID peut être retiré sur les hôtes qui n’utilisent pas l’authentification host-based, qui est rarement déployée en production. La désactivation de ssh-keysign n’affecte pas les fonctionnalités SSH standard (authentification par clé, par mot de passe, par certificat), elle n’impacte que les déploiements utilisant explicitement l’authentification host-based.
Recommandations CERT et perspectives
Pour les équipes CERT, CSIRT et VOC, les actions à anticiper s’ordonnent en trois horizons.
À court terme et immédiatement, il convient d’inventorier les noyaux Linux du périmètre en distinguant les branches antérieures à v4.10-rc1 (non affectées) et les branches postérieures (potentiellement affectées) ; de déployer la mitigation Yama ptrace_scope=3 sur les serveurs de production sans usage légitime de ptrace, et ptrace_scope=2 sur les machines de développement ; d’auditer les profils seccomp des conteneurs et des pods Kubernetes en s’assurant que pidfd_getfd(2) est bloquée par RuntimeDefault ou par un profil explicite ; de cartographier les hôtes exposant un accès local non privilégié à des tiers (hébergeurs mutualisés, runners CI, bastions multi-utilisateurs) et de prioriser leur remédiation ; pour les hôtes n’utilisant pas l’authentification host-based SSH, de retirer le bit SUID sur ssh-keysign en mesure de durcissement.
À court à moyen terme, il s’agit de suivre la publication des kernel updates sur les bulletins distributions officiels (USN Ubuntu, DSA Debian, RHSA Red Hat, ALSA AlmaLinux, CLSA CloudLinux, SUSE-SU) et de planifier les redémarrages associés ; d’évaluer l’opportunité du déploiement de KernelCare livepatch en alternative au redémarrage pour les environnements CloudLinux et AlmaLinux ; d’anticiper la publication du bulletin Qualys officiel, qui apportera vraisemblablement des éléments complémentaires sur les variantes d’exploitation et les implications pour des binaires SUID au-delà de ssh-keysign et chage. Un second article suivra à cette occasion sur le présent blog.
À moyen terme, il convient de réévaluer la posture d’installation par défaut des binaires SUID root, en désactivant le bit SUID sur les binaires non strictement nécessaires aux fonctions opérationnelles de chaque hôte ; d’intégrer CVE-2026-46333 dans les scénarios de threat hunting portant sur les compromissions post-initiales avec accès local non privilégié ; pour les bastions et serveurs SSH critiques, de mettre en place une rotation périodique des clés hôte SSH dans le cadre d’une procédure de remediation systématique en cas de compromission présumée.
Pour les organisations dont une partie du parc repose sur des distributions en fin de support, la question du correctif noyau se pose dans des termes spécifiques. Les options sont, par ordre de préférence en termes de soutenabilité, la migration vers une version supportée, la souscription à un programme de support étendu (Ubuntu Pro / ESM, Red Hat ELS, KernelCare), ou le maintien temporaire avec les mitigations Yama et seccomp en attendant la migration. Le maintien sans aucun support étendu et sans mitigation n’est pas une option soutenable face à un PoC public diffusé et à une classe de vulnérabilité dont d’autres variantes sont raisonnablement à anticiper.
Le présent article constitue la première analyse publiée sur ce blog au sujet de CVE-2026-46333. À la parution du bulletin officiel de Qualys, un second article approfondira les éléments techniques complémentaires, en particulier les variantes d’exploitation explorées par l’équipe de recherche et les implications sur d’autres binaires SUID que ssh-keysign et chage. La séquence ssh-keysign-pwn aura constitué, dans le contexte d’une quinzaine déjà dense (Dirty Frag, Fragnesia, Copy Fail), un marqueur supplémentaire de la transition d’échelle dans la dynamique des découvertes noyau Linux.
