CVE-2026-46333 (ssh-keysign-pwn) : la quatrième vulnérabilité du noyau Linux en trois semaines et quoi faire

Le 14 mai 2026, l'unité de recherche sur les menaces de Qualys a publiquement divulgué CVE-2026-46333, une faille logique du noyau Linux qui permet à tout utilisateur local non privilégié de lire des fichiers appartenant à root, incluant les clés privées SSH de l'hôte et le contenu de /etc/shadow. Une preuve de concept publique nommée ssh-keysign-pwn est disponible sur GitHub. Linus Torvalds a soumis le correctif amont (commit 31e62c2ebbfd) le même jour où le bogue a été divulgué. La faille a six ans, initialement identifiée dans une proposition de correctif de 2020 par Jann Horn qui n'a jamais été fusionnée.

C'est le quatrième problème de sécurité du noyau Linux nécessitant attention en trois semaines, après Copy Fail (29 avril), Dirty Frag (7 mai) et Fragnesia (13 mai). Chacun est un bogue différent avec une atténuation différente, et les atténuations ne se substituent pas les unes aux autres. Si vous avez appliqué la liste noire de modules pour Dirty Frag, elle ne fait rien contre ce problème.

Si vous êtes client d'un serveur géré chez Gotekky, votre serveur a été atténué. Nous avons déployé l'atténuation par sysctl à l'échelle de l'hôte sur la flotte dans les heures suivant la divulgation. Le reste de ce guide explique ce que la vulnérabilité fait, pourquoi celle-ci est structurellement différente des trois précédentes et ce que les opérateurs auto-gérés devraient faire aujourd'hui.

Ce que CVE-2026-46333 fait réellement

Le bogue réside dans __ptrace_may_access(), la fonction du noyau qui décide si un processus peut en inspecter un autre. Spécifiquement, la fonction saute une vérification de sécurité importante (la vérification « dumpable ») quand le processus cible n'a plus de carte mémoire associée (mm == NULL). Cela ressemble à un cas limite obscur, mais c'est exactement l'état dans lequel chaque processus entre pendant sa séquence de sortie : le noyau exécute exit_mm() pour libérer la carte mémoire avant d'exécuter exit_files() pour fermer les descripteurs de fichiers. Il y a une brève fenêtre où le processus en train de mourir n'a pas de carte mémoire mais possède toujours ses descripteurs de fichiers. Pendant cette fenêtre, un utilisateur non privilégié correspondant à l'UID de la cible peut appeler pidfd_getfd(2) et voler les descripteurs de fichiers du processus en train de mourir.

L'exploit choisi par Qualys cible ssh-keysign, un binaire setuid qui est livré sur chaque système Linux où OpenSSH est installé. ssh-keysign est normalement invoqué brièvement par le client SSH pour signer les défis d'authentification avec les clés privées de l'hôte, et pendant cette brève durée de vie, il a les fichiers de clés privées SSH de l'hôte ouverts en tant que root. La preuve de concept fait la course contre la sortie de ssh-keysign, appelle pidfd_getfd sur sa table de descripteurs de fichiers et vole les descripteurs ouverts vers /etc/ssh/ssh_host_ecdsa_key, ssh_host_ed25519_key et ssh_host_rsa_key. Une seconde variante de la preuve de concept cible chage, un autre binaire setuid, et vole le descripteur ouvert vers /etc/shadow, qui contient le hachage de mot de passe de chaque utilisateur sur le système.

La catégorie est divulgation d'information, pas escalade de privilèges. Un attaquant exploitant ceci ne devient pas root directement. Ce qu'il obtient est plus utile à certains égards et moins utile à d'autres : les clés privées SSH de l'hôte lui permettent d'usurper l'identité du serveur pour des attaques d'homme du milieu SSH contre de futures connexions, et le fichier shadow lui donne le hachage de mot de passe de chaque utilisateur pour craquage hors ligne, y compris celui de root. Dans un contexte d'hébergement, c'est le genre de point d'appui qui se transforme en compromission à long terme plutôt qu'en prise de contrôle instantanée.

Pourquoi celle-ci est structurellement différente des trois CVE du noyau précédentes

Copy Fail, Dirty Frag et Fragnesia partagent un schéma : écrire des octets contrôlés par l'attaquant dans le cache de pages du noyau, modifier une copie en mémoire d'un binaire privilégié, puis l'exécuter pour un root instantané. Les atténuations pour ces trois sont toutes des listes noires de modules (esp4, esp6, algif_aead, rxrpc, ipcomp4, ipcomp6) plus un vidage du cache de pages. CVE-2026-46333 ne fait rien de cela. Elle n'écrit rien nulle part. Elle fait la course contre la sortie de processus et lit des descripteurs de fichiers d'un processus en train de mourir. Le cache de pages n'est pas impliqué. ESP, XFRM, rxrpc et algif_aead ne sont pas impliqués.

Cela signifie que les atténuations existantes sur vos serveurs ne protègent pas contre CVE-2026-46333. Un serveur qui a les listes noires Dirty Frag et Fragnesia en place est encore vulnérable ici. Vous avez besoin d'une atténuation séparée, et la bonne nouvelle est qu'elle est plus simple que les trois précédentes. La mauvaise nouvelle est que vous devez l'appliquer explicitement.

L'atténuation est un seul sysctl du noyau : kernel.yama.ptrace_scope. Le module de sécurité Linux Yama restreint quels processus peuvent utiliser ptrace et les API connexes sur quels autres processus. Le chemin de la vulnérabilité via pidfd_getfd vérifie les permissions ptrace_may_access. En durcissant le ptrace_scope de Yama à son réglage le plus restrictif (3, qui interdit tout attachement ptrace pour les processus sans CAP_SYS_PTRACE), le noyau rejette la tentative d'exploitation avant que le chemin de code bogué ne soit atteint. Le réglage est entièrement réversible avec une seule écriture sysctl.

Versions CloudLinux affectées

CloudLinux a publié des conseils spécifiques par version pour ce CVE. L'état actuel est :

• CloudLinux 8 LTS, CloudLinux 9, CloudLinux 10 : affectées et exploitables par la preuve de concept publique actuelle. Appliquez l'atténuation immédiatement.
• CloudLinux 7h et CloudLinux 8 : la course de noyau sous-jacente est présente, mais la preuve de concept publique ne fonctionne pas contre elles car l'appel système pidfd_getfd n'est pas exposé sur leur ligne de noyau. Elles recevront des correctifs sur la même chronologie que les autres versions. Appliquez l'atténuation comme défense en profondeur même si l'exploit public ne fonctionne pas aujourd'hui, car une variante indépendante du syscall pourrait être développée.
• CloudLinux 7 : pas affectée.

Pour AlmaLinux, les versions affectées sont 8, 9 et 10. AlmaLinux 7 est en fin de vie et n'est pas affectée par ce CVE spécifique en raison de sa ligne de noyau plus ancienne. Le même schéma d'atténuation s'applique sur AlmaLinux comme sur CloudLinux car les deux partagent le noyau Linux amont et le même LSM Yama. Les noyaux corrigés CloudLinux et AlmaLinux et un livepatch KernelCare sont en construction et test active au moment de la rédaction.

Ce que Gotekky a fait sur les serveurs gérés

Dans les heures suivant la divulgation, nous avons déployé le réglage sysctl kernel.yama.ptrace_scope=3 sur chaque serveur géré dans notre infrastructure de Toronto, persisté via /etc/sysctl.d/ et vérifié la valeur en cours d'exécution sur chaque nœud. C'est une atténuation à l'échelle de l'hôte qui prend effet immédiatement, ne nécessite aucun redémarrage, n'a aucun impact mesurable sur les performances et n'interagit pas avec les atténuations Dirty Frag ou Fragnesia existantes. Les quatre atténuations sont maintenant en place simultanément sur chaque serveur géré.

Pour les serveurs gérés CloudLinux avec KernelCare, nous appliquerons le livepatch corrigé dès que CloudLinux le publiera, après quoi l'atténuation sysctl devient une défense en profondeur mais reste en place. Pour les nœuds AlmaLinux, nous appliquerons le noyau corrigé pendant la prochaine fenêtre de maintenance planifiée. Les clients sur des plans gérés par Gotekky n'ont aucune action à prendre.

Si vous exploitez des serveurs auto-gérés, faites ceci aujourd'hui

L'atténuation est un seul changement sysctl. En tant que root :

echo 3 > /proc/sys/kernel/yama/ptrace_scope
echo "kernel.yama.ptrace_scope = 3" > /etc/sysctl.d/cve-2026-46333.conf
sysctl --system

La première ligne prend effet immédiatement sur le noyau en cours d'exécution. Les deuxième et troisième lignes font survivre le changement aux redémarrages en l'ajoutant à un fichier de configuration sysctl.d. Vérifiez avec :

sysctl kernel.yama.ptrace_scope
# Sortie attendue : kernel.yama.ptrace_scope = 3

Si ceci retourne une valeur autre que 3 après l'exécution des commandes ci-dessus, vérifiez que Yama est effectivement compilé dans votre noyau (cat /sys/kernel/security/lsm devrait inclure yama dans la sortie). Sur presque toutes les distributions modernes, Yama est activé par défaut, donc c'est rarement un problème, mais les conteneurs et les builds de noyau minimaux peuvent l'omettre.

Ce que ptrace_scope=3 fait réellement et ce qu'elle casse

Le sysctl ptrace_scope de Yama a quatre réglages. La plupart des distributions modernes ont par défaut 1 (qui restreint ptrace aux relations parent-enfant seulement). Le régler à 3 signifie qu'aucun attachement ptrace n'est permis du tout, y compris parent-enfant. Une fois réglé à 3, le sysctl ne peut pas être ramené sans redémarrage.

Conséquences pratiques sur un serveur d'hébergement :

• L'attachement de gdb aux processus en cours d'exécution est cassé. Lancer gdb contre un binaire directement fonctionne encore car cela crée un processus enfant. Attacher gdb à un PID existant ne fonctionne pas.
• strace -p PID est cassé. Tracer un processus que vous avez lancé (strace progname) fonctionne encore.
• perf record -p PID est cassé. Le perf à l'échelle du système fonctionne encore.
• Les gestionnaires de plantage dans les navigateurs (Chromium, Firefox) ne peuvent pas capturer les dumps de plantage via ptrace. Les serveurs d'hébergement n'exécutent typiquement pas de navigateurs de bureau, donc c'est rarement pertinent.
• Certains agents de surveillance qui utilisent ptrace cessent de collecter des données par processus. La plupart de l'observabilité moderne utilise eBPF ou /proc plutôt que ptrace, mais vérifiez votre pile de surveillance.

Pour les serveurs cPanel, Webuzo, Plesk et DirectAdmin, aucune de ces conséquences n'a typiquement d'importance. Les clients n'exécutent pas gdb sur des environnements d'hébergement de production et les propres outils de diagnostic du panneau ne dépendent pas de l'attachement aux PID en cours d'exécution. Pour un serveur d'ingénierie interne de Gotekky où l'équipe a véritablement besoin d'attacher des débogueurs à des processus en cours d'exécution, nous utilisons un retour temporaire à ptrace_scope=0 pendant la session de dépannage, puis restaurons à 3 avec un redémarrage. Le fait que le réglage soit à sens unique jusqu'au redémarrage fait partie de sa valeur de sécurité : un attaquant qui obtient brièvement root ne peut pas trivialement l'abaisser au réglage vulnérable et persister.

Si vous devez annuler l'atténuation temporairement

Comme ptrace_scope=3 est persistant jusqu'au redémarrage, l'annulation nécessite de retirer le réglage persistant et de redémarrer :

rm /etc/sysctl.d/cve-2026-46333.conf
reboot

Après redémarrage, le système retourne à son défaut précédent (généralement 1 sur les distributions modernes). Si vous n'avez besoin de ptrace que temporairement pour une seule session de débogage, c'est le bon chemin. Pour un changement permanent, éditez le fichier de persistance plutôt que de le supprimer.

CloudLinux avec KernelCare

Si vous exécutez CloudLinux 7h, 8 LTS, 8, 9 ou 10 avec KernelCare, un livepatch pour CVE-2026-46333 est en construction active. Une fois publié, il se déploie automatiquement sans redémarrage. Vérifiez le statut avec :

kcarectl --update
kcarectl --patch-info | grep CVE-2026-46333

Si le CVE apparaît comme corrigé, votre noyau est fixé à la source et l'atténuation sysctl devient optionnelle. Nous recommandons de laisser le sysctl en place de toute façon comme défense en profondeur, car ptrace_scope=3 défend aussi contre d'autres problèmes liés à ptrace qui pourraient surfacer dans le futur.

Pour AlmaLinux sans KernelCare

Les noyaux corrigés pour AlmaLinux 8, 9 et 10 suivront le même chemin de publication que les noyaux Fragnesia la semaine dernière (dépôt de test d'abord, puis production). Une fois publiés :

sudo dnf clean metadata
sudo dnf upgrade kernel
sudo reboot

Jusque-là, l'atténuation sysctl est suffisante. Le correctif dans le commit du noyau amont 31e62c2ebbfd sera rétroporté aux branches AlmaLinux prises en charge dans les prochains jours.

Considérations d'audit et de rotation des identifiants

Les vulnérabilités de divulgation d'information soulèvent une question que les bogues d'escalade de privilèges purs ne soulèvent pas : l'exploitation s'est-elle produite avant l'atténuation ? CVE-2026-46333 a été un bogue latent de six ans, et bien que la preuve de concept publique n'ait été publiée que le 14 mai 2026, il est possible que cette primitive ait été connue en privé par certains attaquants plus tôt.

Pour un serveur d'hébergement, la posture conservatrice est de traiter les clés SSH de l'hôte et le fichier shadow comme potentiellement compromis sur tout serveur qui était joignable depuis internet avec accès shell pour des utilisateurs non fiables avant l'application de l'atténuation. La remédiation dans ce cas est :

• Faire tourner les clés SSH de l'hôte. Générez de nouvelles clés d'hôte, redémarrez sshd et acceptez que les clients SSH récurrents verront un avertissement de changement de clé d'hôte jusqu'à ce que leur known_hosts soit mis à jour. Spécifiquement : rm /etc/ssh/ssh_host_*_key* et exécutez ssh-keygen -A ou systemctl restart ssh pour régénérer.
• Forcer la réinitialisation des mots de passe pour tous les comptes locaux dont les hachages étaient sur le système. Le fichier shadow contient le hachage de mot de passe de chaque compte. Le craquage hors ligne sur les GPU modernes rend les mots de passe faibles récupérables. Forcez la rotation du mot de passe de root et de chaque compte utilisateur.
• Surveillez les schémas d'authentification SSH inhabituels au cours des prochaines semaines. Si les clés d'hôte ont été exfiltrées, l'abus le plus probable est une attaque d'homme du milieu où l'attaquant usurpe l'identité de votre serveur pour intercepter les connexions SSH des administrateurs. La journalisation et l'alerte sur le comportement inhabituel des clients SSH sont le bon contrôle défensif.

C'est un travail lourd pour ce qui peut avoir été zéro compromission réelle. Pour la plupart des serveurs d'hébergement qui ont fonctionné sous une surveillance normale sans tentatives d'intrusion connues, traiter le problème comme un correctif préventif (appliquer l'atténuation, planifier la mise à niveau du noyau, pas de rotation) est raisonnable. La discussion de rotation est pour les environnements où vous avez une raison spécifique de soupçonner une exploitation antérieure ou où des cadres de conformité comme SOC 2, PCI DSS ou les règles de notification de violation de la LPRPDE exigent une réponse plus conservatrice.

Le schéma que cela représente

Quatre vulnérabilités du noyau Linux en trois semaines, trouvées par quatre groupes de recherche différents, dans quatre sous-systèmes du noyau différents, avec quatre schémas d'exploitation différents. Les leçons des divulgations précédentes tiennent : la revue de code assistée par IA est maintenant véritablement efficace pour trouver des primitives déterministes comme celles-ci, et le type de bogue trouvé est celui que le chercheur a entraîné son outillage à chercher. Copy Fail et Dirty Frag et Fragnesia étaient une famille d'écriture dans le cache de pages. CVE-2026-46333 est une famille ptrace-pendant-la-sortie. Aucune famille n'est épuisée par ces divulgations, et des bogues similaires dans des zones adjacentes (livraison de signaux pendant la sortie, démantèlement d'espaces de noms, nettoyage de descripteurs de fichiers) sont des candidats plausibles pour la prochaine divulgation.

Pour l'infrastructure d'hébergement canadienne opérant sous la LPRPDE, la Loi 25 au Québec et les cadres SOC 2, la réalité opérationnelle est que les fenêtres de correctifs mensuelles ne sont pas suffisantes quand les divulgations d'urgence arrivent à peu près chaque semaine. La défense en profondeur, le déploiement automatisé des atténuations et un manuel de réponse aux incidents pour les CVE du noyau sont maintenant la base. Gotekky a investi dans cela tout au long de 2026 et la cadence de réponse sur ces quatre divulgations reflète ce travail. Nous continuerons à publier des guides à mesure que de nouvelles divulgations arrivent et à mettre à jour les stratégies d'atténuation au fur et à mesure que le paysage des menaces évolue.

La posture de sécurité actuelle complète sur un serveur géré par Gotekky inclut maintenant : le correctif cPanel et WHM CVE-2026-41940 du 28 avril, le correctif WHMCS CVE-2026-29204 du 13 mai, la liste noire de module algif_aead pour Copy Fail, la liste noire des modules esp4/esp6/ipcomp4/ipcomp6/rxrpc pour Dirty Frag et Fragnesia et maintenant kernel.yama.ptrace_scope=3 pour CVE-2026-46333. Chacune est indépendante. Chacune est nécessaire. Nous avons publié des guides séparés pour les problèmes cPanel et WHMCS et un guide dédié pour chacun des quatre CVE du noyau, et nous recommandons de lire le guide pertinent en détail si vous exploitez des serveurs auto-gérés.