La liste que tout le monde veut n’existe pas. OpenAI a publié son rapport, « A thousand fewer paths to root », le 4 novembre 2026, et le rapport ne nomme aucun identifiant CVE, aucune version de noyau touchée et aucun sous système. Notre reportage sur les 948 exploits couvre les comptes, les coûts et les affirmations. Ce tutoriel couvre la machine devant vous, et il part d’une position honnête : vous ne pouvez pas vérifier un serveur par rapport à une liste que personne n’a publiée.
Ce que vous pouvez vérifier est tout ce qui entoure cette liste manquante. Un exploit dans cette classe part d’un compte local ordinaire et se termine à root. Alors l’état de vos mises à jour du noyau, de votre file de redémarrage, de votre couverture de correctifs en direct, de vos comptes locaux et de vos valeurs de durcissement du noyau décide de la place qu’un tel exploit aurait sur vos machines aujourd’hui. Rien de cela n’a besoin de la liste CVE. Tout cela est du travail que vous voudriez fait même si la liste arrivait demain.
Ce que vous allez construire ou apprendre
Vous terminerez avec un registre écrit pour un serveur, construit à partir de ses propres réponses. Le registre énonce quel noyau fonctionne, quelle version de distribution la machine exécute, si une mise à jour du noyau attend d’être installée, si un redémarrage est déjà dû, si un service de correctifs en direct couvre le noyau en marche, quels comptes locaux existent et ce que six valeurs de durcissement lisent sur cette machine.
Vous terminerez aussi avec une lecture claire des chiffres OpenAI. Le pipeline a produit 1 169 exploits d’élévation de privilèges locaux qui fonctionnent, et l’analyse des variantes a groupé ces exploits en 948 failles distinctes, chacune avec un correctif candidat. Candidat est le mot qui compte. Un correctif candidat devient une vraie correction seulement quand les mainteneurs du noyau l’acceptent et que votre distribution le livre. Dix jours après le balayage de la mi octobre, OpenAI dit que 61 des failles avaient déjà été corrigées en amont, 43 avaient des correctifs en préparation et 299 étaient signalées et discutées en public. Le reste avançait encore dans la divulgation. C’est pourquoi la réponse pratique aujourd’hui est la cadence des correctifs et l’exposition locale, pas une chasse à 948 noms.
Avant de commencer
Trois limites façonnent toute cette vérification, et chacune vous protège d’une mauvaise conclusion.
Premièrement, la liste manquante est réelle. Le rapport OpenAI donne des comptes, des coûts par étape et un état des correctifs, et il ne donne aucun identifiant qu’un outil pourrait relier à votre noyau. Tout numériseur, billet de blogue ou argumentaire de fournisseur qui prétend tester vos serveurs pour les 948 par nom invente la liste contre laquelle il teste. Traitez une telle affirmation comme du marketing et demandez ses données sources.
Deuxièmement, une chaîne de version de noyau n’est pas un verdict. Les distributions transportent des corrections de sécurité dans des numéros de version plus vieux, une pratique appelée rétroportage, alors un noyau qui semble vieux à côté de la plus récente version en amont peut déjà porter une correction donnée. L’inverse tient aussi. Un nouveau paquet de noyau peut se trouver installé sur le disque pendant que la machine exécute encore le vieux noyau avec lequel elle a démarré la semaine dernière. Jugez par les avis de la distribution et par l’état des paquets sur la machine, jamais en comparant les numéros de version avec l’amont seul.
Troisièmement, l’élévation de privilèges locale a besoin d’un départ local. L’attaquant a besoin de code qui fonctionne comme un utilisateur ordinaire sur la boîte d’abord : une personne avec un compte, un compte de service pour une application ou une charge de travail dans un conteneur. Ce fait établit l’ordre de ce tutoriel. L’état du noyau d’abord, puis les comptes et les charges de travail qui pourraient donner à un attaquant la position de départ.
Étape 1 : enregistrer le noyau en marche et la distribution
Action : sur le serveur, lancez ces commandes et enregistrez la sortie dans un fichier de registre nommé pour l’hôte :
uname -r
cat /etc/os-release
{ uname -a; cat /etc/os-release; } > kernel-audit-$(hostname).txt
La première commande affiche la version du noyau qui fonctionne en ce moment, sous une forme comme 6.8.0-100-generic. Le fichier /etc/os-release nomme la distribution et sa version, qui est la paire qui décide quels avis et quels noms de paquets s’appliquent à vous. La troisième commande écrit les deux réponses dans un petit fichier que vous pouvez garder à côté du reste de cette vérification.
Résultat attendu : vous tenez trois faits par écrit, le nom d’hôte, la version du noyau en marche et la version de la distribution. Chaque étape ultérieure se lit par rapport à ces trois faits. Si la version du noyau en marche vous surprend, cette surprise est elle même un résultat, et l’étape 2 explique la cause la plus fréquente.
La vérification commence sur papier : un registre par serveur, construit à partir de ce que la machine signale à son propre sujet. Illustration générée dans le style maison de Dirty Static.
Étape 2 : trouver les mises à jour du noyau en attente et l’état de redémarrage
Action, sur Debian et Ubuntu : rafraîchissez les listes de paquets, puis demandez quels paquets de noyau attendent d’être installés. Le rafraîchissement ne change aucun paquet. Il met seulement à jour les listes contre lesquelles votre machine se compare.
sudo apt update
apt list --upgradable 2>/dev/null | grep -E '^linux-(image|generic|headers)'
dpkg -l 'linux-image-*' | grep '^ii'
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
Les deux premières commandes montrent si un paquet de noyau plus récent est offert. La troisième liste les paquets de noyau déjà installés sur le disque, et comparer sa plus récente entrée avec la sortie uname -r de l’étape 1 vous dit si un noyau installé n’a jamais été démarré. Les deux dernières commandes lisent le marqueur de redémarrage. Le fichier /var/run/reboot-required existe seulement quand une mise à jour installée a demandé un redémarrage, et son fichier compagnon nomme les paquets qui l’ont demandé. Si la commande ls signale que le fichier n’existe pas, cette erreur est la réponse : aucun redémarrage n’est marqué comme dû.
Action, sur la famille RHEL :
dnf check-update
rpm -q kernel
sudo needs-restarting -r
La première commande affiche les mises à jour offertes, et elle sort avec le code 100 quand des mises à jour existent, ce qui est une information et non un échec. La deuxième liste les paquets de noyau installés pour la même comparaison avec uname -r. La troisième signale si le système en marche a besoin d’un redémarrage pour utiliser des mises à jour déjà installées. L’outil needs-restarting est livré dans le paquet dnf-utils, alors une commande manquante signifie que ce paquet est absent, et la comparaison uname ci dessus est votre preuve jusqu’à ce que vous l’installiez.
Résultat attendu : une de trois lectures par serveur. Une mise à jour du noyau attend, ce qui vous envoie à l’étape 6. Ou un noyau est installé et un redémarrage est dû, ce qui vous envoie aussi à l’étape 6 et explique tout résultat étrange de l’étape 1. Ou rien n’attend et rien n’est dû, ce qui signifie que votre distribution n’a aucun noyau plus récent pour vous aujourd’hui, et les étapes restantes décident de votre posture.
Étape 3 : lire l’état des correctifs en direct là où un service existe
Certains serveurs reçoivent des corrections pour de graves failles du noyau appliquées au noyau en marche, sans redémarrage, par un service de correctifs en direct. Le service couvre seulement les failles que son fabricant juge sûres à corriger de cette façon, et il ne déplace jamais une machine vers un noyau plus récent. C’est un pont entre les redémarrages, et cette étape lit si le pont est vraiment en place.
Action, sur Ubuntu :
pro status
sudo canonical-livepatch status
La première commande montre si le service livepatch est activé. La deuxième montre le noyau en marche qu’il protège et son état de correctif. Lisez la ligne d’état de correctif au pied de la lettre : elle vous dit si des correctifs sont appliqués, si aucun n’est encore nécessaire ou si le noyau en marche n’est pas pris en charge par le service du tout. Un noyau non pris en charge ne reçoit rien du service, quoi que l’abonnement dise, selon la documentation Ubuntu Pro.
Action, sur les systèmes RHEL qui utilisent kpatch :
sudo kpatch list
Résultat attendu : l’outil liste les correctifs en direct chargés et installés pour le noyau en marche, ou il signale que l’outil est absent, auquel cas enregistrez qu’aucun service de correctifs en direct ne fonctionne sur ce serveur. Sur tout système sans service de correctifs en direct, enregistrez la même réponse simple et fiez vous aux étapes 2 et 6. Un blanc ici n’est pas un échec de la vérification. C’est le fait que les redémarrages sont votre seule voie vers les corrections du noyau sur cette boîte.
Étape 4 : compter les comptes locaux d’où un exploit partirait
Action : listez les comptes ordinaires sur le serveur. Sur la plupart des systèmes, les comptes pour les personnes commencent à l’identifiant d’utilisateur 1000, et le compte nommé nobody se trouve bien au dessus de cette plage, alors ce filtre montre les comptes humains et de service qui comptent :
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $6, $7}' /etc/passwd
getent group sudo
getent group wheel
who
Lisez la sortie comme un appel nominal. La première commande affiche chaque nom de compte, son dossier personnel et son shell de connexion. Les deux commandes suivantes nomment les membres des groupes qui peuvent gagner root par conception, sudo sur Debian et Ubuntu et wheel sur la famille RHEL. Un exploit qui atteint root depuis un compte ordinaire rend ces listes de groupes plus importantes, pas moins, parce qu’elles montrent qui détient déjà une voie gérée vers le haut. La dernière commande montre qui est connecté maintenant.
Chaque compte local est une clé sur le mur. La vérification les compte et vérifie lesquelles vous reconnaissez. Illustration générée dans le style maison de Dirty Static.
Action : si le serveur exécute des conteneurs, listez les et vérifiez si certains fonctionnent en mode privilégié :
docker ps
docker ps -q | xargs -r docker inspect --format '{{.Name}} privileged={{.HostConfig.Privileged}}'
Utilisez les équivalents podman sur les systèmes qui exécutent Podman. Si aucun des deux outils n’existe, enregistrez le et passez à autre chose. Les conteneurs partagent le noyau de l’hôte, alors corriger une image de conteneur ne fait rien pour une faille du noyau. L’hôte est la cible, et un conteneur qui fonctionne avec privileged réglé à true détient un large accès à cet hôte, alors chaque tel conteneur appartient à votre liste de positions de départ à côté des comptes humains.
Résultat attendu : une liste de comptes et de charges de travail que vous reconnaissez, chacun possédé par une personne ou un service que vous pouvez nommer. Tout nom que vous ne pouvez pas placer est le résultat le plus précieux de cette étape. Retirez ou désactivez un compte seulement par votre processus de changement normal, avec le propriétaire du service dans la boucle, parce qu’un compte de service qui semble inactif peut encore exécuter un travail de nuit.
Étape 5 : lire les valeurs de durcissement qui façonnent l’accès au noyau
Les réglages du noyau, lus et changés avec l’outil sysctl, décident quelle part du noyau un utilisateur ordinaire peut toucher ou voir. Cette étape lit seulement six valeurs. Elle n’en change aucune, et les notes ci dessous expliquent ce que chaque lecture signifie pour que vous puissiez l’enregistrer avec compréhension plutôt que comme un chiffre nu.
Action : lancez :
sysctl kernel.kptr_restrict kernel.dmesg_restrict kernel.perf_event_paranoid kernel.unprivileged_bpf_disabled
sysctl user.max_user_namespaces
sysctl kernel.unprivileged_userns_clone
La troisième commande peut signaler que la clé n’existe pas. Cette clé est livrée seulement sur certaines distributions, surtout la famille Debian, alors une erreur là signifie que le contrôle est absent sur ce noyau. Enregistrez absent comme absent. Ne l’enregistrez pas comme zéro, parce que les deux lectures signifient des choses différentes.
Comment lire les valeurs, par rapport à la documentation du noyau :
kernel.kptr_restrictcontrôle si les adresses de mémoire du noyau sont cachées quand elles sont affichées. À 1, les adresses sont remplacées par des zéros pour les utilisateurs qui n’ont pas la capacité CAP_SYSLOG, avec des conditions que la documentation énonce. À 2, elles sont mises à zéro pour tout le monde. À 0, les adresses sont hachées avant l’affichage. Plus c’est élevé, plus c’est serré, et cette valeur porte sur le côté fuite d’information des résultats OpenAI.kernel.dmesg_restrictà 1 signifie que seuls les utilisateurs avec CAP_SYSLOG peuvent lire le journal du noyau par l’outil dmesg. À 0, tout utilisateur local peut le lire.kernel.perf_event_paranoidcontrôle l’outil de mesure perf. Des chiffres plus élevés le restreignent davantage, et les distributions livrent des défauts différents, y compris une valeur de 4 sur Ubuntu que l’amont ne définit pas. Enregistrez le chiffre et comparez le avec votre propre flotte plutôt qu’avec un tableau universel, parce qu’aucun défaut universel n’existe.kernel.unprivileged_bpf_disabledà 1 ou 2 signifie que les utilisateurs ordinaires ne peuvent pas faire d’appels non privilégiés dans eBPF, la machine virtuelle dans le noyau qu’une longue série de failles d’élévation passées a abusée. La documentation du noyau ajoute un avertissement qui vaut la peine d’être connu avant que vous régliez jamais cette valeur vous même : une fois réglée à 1, le réglage ne peut pas être effacé jusqu’à ce que la machine redémarre.user.max_user_namespacesplafonne le nombre d’espaces de noms d’utilisateur qui peuvent être créés. Une valeur de 0 ferme la création entièrement. Une grande valeur laisse la création ouverte, sous réserve d’autres contrôles.kernel.unprivileged_userns_clone, là où il existe, à 0 signifie que seuls les utilisateurs privilégiés peuvent créer des espaces de noms d’utilisateur. Les espaces de noms d’utilisateur sont un outil de bac à sable dont beaucoup d’installations de conteneurs et de navigateurs dépendent, et ils sont aussi un point d’entrée fréquent dans les exploits d’élévation passés, parce qu’un espace de noms donne à son créateur des privilèges relevés dedans sur des objets du noyau que l’hôte peut voir.
Résultat attendu : six lectures, ou cinq lectures plus une absence enregistrée, par serveur. Ce tutoriel ne vous dit pas de changer aucune d’elles sur une machine de production aujourd’hui. Changer les réglages d’espaces de noms ou d’eBPF peut briser les conteneurs sans root, les bacs à sable et les outils qui en dépendent, alors chaque changement appartient à un test sur un hôte de rechange d’abord, un changement à la fois, avec une voie de retour.
Étape 6 : installer le noyau que votre distribution offre, puis redémarrer
Action, sur Debian et Ubuntu :
sudo apt update
sudo apt full-upgrade
sudo reboot
Action, sur la famille RHEL :
sudo dnf update
sudo reboot
Là où votre politique permet les mises à jour de sécurité seulement, ajoutez le drapeau de sécurité à la commande dnf à la place d’une mise à jour complète, et acceptez que d’autres paquets attendent alors leur propre fenêtre. Après le retour de la machine, répétez l’étape 1 et l’étape 2 sur elle.
Résultat attendu : uname -r affiche maintenant la version de noyau plus récente que l’étape 2 montrait comme installée, la liste des paquets de noyau à mettre à niveau est vide et le marqueur de redémarrage a disparu. Si uname -r affiche encore l’ancienne version, la machine a démarré son noyau précédent, et le tableau de dépannage ci dessous couvre cette lecture.
Vérification
La vérification a fonctionné quand votre registre place chaque serveur dans exactement une rangée de ce tableau, avec des preuves tirées de la machine elle même.
| Preuve tirée de votre registre | Lecture |
|---|---|
| Mise à jour du noyau en attente à l’étape 2, ou marqueur de redémarrage présent | Exposé par le retard. La correction existe et la machine ne l’exécute pas. L’étape 6 est tout le remède, dans une fenêtre. |
| Noyau installé plus récent que le noyau en marche | Même lecture que ci dessus, avec la cause nommée. La mise à jour a atterri et le redémarrage n’a jamais eu lieu. |
| Service de correctifs en direct activé, noyau pris en charge, état de correctif appliqué ou aucun nécessaire | Couvert entre les redémarrages pour les failles que le service choisit. Les mises à jour normales du noyau s’appliquent encore à leur cadence normale. |
| Réponse de correctifs en direct absente ou noyau non pris en charge, et aucune mise à jour en attente | À jour par la voie des paquets seulement. Votre posture est votre cadence de redémarrage, et rien d’autre ne se tient entre une faille et sa correction. |
| Un compte ou un conteneur privilégié que personne ne peut nommer | Une position de départ que vous ne saviez pas offrir. Réglez la par votre processus de changement avant de vous soucier des valeurs du noyau. |
| Création d’espaces de noms ouverte et eBPF non privilégié activé sur un serveur qui exécute des charges locales non fiables | Une surface locale plus large que ce dont la tâche a besoin. Un candidat pour un resserrement testé plus tard, jamais une modification le jour même sur une boîte de production. |
| Aucune mise à jour en attente, comptes tous nommés, état des correctifs en direct lu et enregistré | Aussi à jour qu’aujourd’hui le permet. Aucune vérification ne peut en dire plus pendant que les 948 ne portent aucun identifiant, et quiconque prétend plus devine. |
Dépannage
| Problème | Cause probable | Correctif |
|---|---|---|
uname -r montre encore l’ancien noyau après l’étape 6 | La machine a redémarré dans son noyau précédent, ou le nouveau paquet de noyau s’est installé sans devenir le défaut de démarrage | Comparez la liste installée de l’étape 2 avec la version en marche, vérifiez la sélection du menu du chargeur de démarrage, redémarrez une fois de plus et lisez uname -r de nouveau avant de juger. |
| Le numéro du noyau en marche semble plus vieux que le plus récent noyau en amont, pourtant la distribution liste la classe de faille comme corrigée | Rétroportage. La distribution a transporté la correction dans son propre numéro de version | Faites confiance à l’avis de la distribution et au journal des changements du paquet pour votre version exacte plutôt qu’à toute comparaison de chiffres en amont. |
needs-restarting est introuvable | Le paquet dnf-utils n’est pas installé sur les systèmes de la famille RHEL | Installez dnf-utils par votre processus normal, ou fondez le jugement de redémarrage sur la comparaison installé contre en marche à l’étape 2. |
canonical-livepatch status dit que le noyau n’est pas pris en charge | Le noyau en marche se trouve hors de la liste que le service Livepatch couvre | Le service n’applique rien à ce noyau. Déplacez la machine vers un noyau pris en charge par l’étape 6 et lisez l’état de nouveau. |
sysctl signale que kernel.unprivileged_userns_clone n’existe pas | La clé est livrée seulement sur certaines distributions | Enregistrez le contrôle comme absent sur ce noyau. Jugez l’exposition aux espaces de noms par la lecture user.max_user_namespaces à la place. |
dnf check-update se termine avec un message de style erreur et le code 100 | Le code 100 est le signal documenté que des mises à jour existent | Lisez la liste affichée. C’est un résultat, pas un échec. |
| Aucune mise à jour du noyau n’est offerte et les nouvelles semblent urgentes | Aucun noyau plus récent n’a encore été publié pour votre version, ce qui est l’état normal pendant que les 948 avancent dans la divulgation | Gardez votre cadence normale, gardez le registre de cette vérification et revérifiez après que votre distribution publie son prochain noyau. N’installez pas de noyaux hors de vos canaux de distribution comme raccourci. |
| Un changement de durcissement a brisé un conteneur ou un bac à sable en test | La charge de travail dépend des espaces de noms d’utilisateur ou d’eBPF non privilégié | Renversez ce seul changement sur l’hôte de test, enregistrez la dépendance et délimitez tout changement ultérieur aux serveurs qui n’exécutent pas cette charge de travail. |
Prochaines étapes
Transformez cette vérification en rythme plutôt qu’en événement. Abonnez vous aux avis de sécurité de la distribution que chaque serveur exécute, Ubuntu Security Notices, le traqueur de sécurité Debian ou les données de sécurité Red Hat, et laissez ces flux piloter votre cadence de noyau plutôt que les titres. Là où votre politique le permet, activez l’installation automatique des mises à jour de sécurité, par le paquet unattended-upgrades sur la famille Debian ou dnf-automatic sur la famille RHEL, tout en gardant les redémarrages comme des événements planifiés que vous contrôlez.
Surveillez ensuite la seule chose qui changerait ce tutoriel : les identifiants. Quand les rapports de l’exécution OpenAI atteindront les mainteneurs et le registre public, les affectations CVE et les avis de distribution donneront enfin une liste aux défenseurs. Revérifiez vos registres de l’étape 1 le jour où votre distribution publie des corrections de noyau liées à ces affectations, et attendez vous à ce que ce jour arrive par étapes sur des semaines, pas comme une seule tombée. Jusque là, les serveurs qui sortent de cette vérification avec des noyaux à jour, de courtes listes de comptes et des registres honnêtes sont aussi défendus que les faits publics le permettent.
Commandes et significations des valeurs vérifiés par rapport à la documentation sysctl du noyau Linux, à la documentation Livepatch d’Ubuntu Pro et au billet de recherche OpenAI, novembre 2026. Cette vérification a été vérifiée par rapport à ces documents et n’a pas été exécutée contre un serveur de production dans ce passage, alors confirmez chaque lecture sur votre propre matériel comme le tableau de vérification le dirige.
Sources
- OpenAI, A thousand fewer paths to root, November 4, 2026. Primary source for the 948 distinct flaws, the 1,169 working exploits, the candidate patch status, the patching counts ten days after the scan, and the absence of CVE identifiers, affected versions, and subsystems from the report.
- Dirty Static, OpenAI Says Its Agents Built Working Exploits for 948 Distinct Linux Kernel Root Flaws, November 5, 2026. The news report this tutorial follows, for the counts, costs, and disclosure status in one place.
- The Linux Kernel documentation, Documentation for /proc/sys/kernel/. Source for the meanings of kptr_restrict, dmesg_restrict, and unprivileged_bpf_disabled, including the rule that a value of 1 for the eBPF control cannot be cleared until reboot.
- Ubuntu Pro Client documentation, How to manage Livepatch. Source for the pro status and canonical-livepatch status commands and for the warning an unsupported kernel produces.
- CSO Online, OpenAI built an AI pipeline to find, exploit and patch Linux flaws, November 2026. Independent coverage used to cross check the pipeline counts and the patching status.
- Hero and body images: Dirty Static, generated in house style
FIN DE LA TRANSMISSION
Restez curieux. Remettez tout en question.
