948 exploits d'élévation de privilèges dans le noyau Linux trouvés par les agents d'OpenAI : ce qui attend les admins de VPS

Le 4 novembre 2026, OpenAI a publié un rapport intitulé « A thousand fewer paths to root ». Un pipeline d'agents autonomes a analysé environ 7 % du code du noyau Linux à la mi-octobre et en a tiré 2 308 findings, 1 724 vulnérabilités reproduites et 948 exploits d'élévation de privilèges locale (LPE, local privilege escalation). Chacun de ces exploits donne les droits root à un utilisateur local qui n'a aucun privilège. Dix jours après le scan, 61 failles étaient déjà corrigées upstream, 43 attendaient en staging et 299 étaient en cours de signalement public. Pour quiconque administre un VPS Linux ou un serveur dédié qui héberge des serveurs de jeu, un panel Pterodactyl ou des conteneurs Docker, cela annonce des semaines de mises à jour du noyau et pose une question simple : qui peut exécuter du code sur votre machine ?

Source : A thousand fewer paths to root, OpenAI, 4 novembre 2026. État des branches du noyau vérifié sur kernel.org.

Ce qu'OpenAI a réellement publié

Le rapport décrit un prototype de recherche, pas un produit. Des agents « scouts » ont d'abord sélectionné dans le noyau Linux (plus de 40 millions de lignes de code) les zones accessibles à un utilisateur sans privilège : 5 034 cibles d'audit, soit environ 2,8 millions de lignes. Des agents d'analyse ont ensuite produit des findings candidats, chaque vulnérabilité a été reproduite dynamiquement dans une machine virtuelle équipée de KASAN (le détecteur d'erreurs mémoire du noyau), puis les candidats exploitables ont été transformés en exploits fonctionnels. Les exploits ont été testés contre une distribution Linux standard avec les protections habituelles activées : SMEP, SMAP et KASLR. Le modèle utilisé est un futur modèle « cyber » d'OpenAI, non nommé et non disponible publiquement.

Trois détails du rapport comptent pour un administrateur système. D'abord, le chiffre de 948 compte des failles distinctes, définies par le correctif qui ferme chacune d'elles, et non des correctifs déjà fusionnés dans le noyau. Ensuite, OpenAI compare ce résultat à un passage fin juillet avec GPT-5.6 Sol, qui avait produit 166 exploits LPE uniques pour 513 690 $ : le rendement a été multiplié par plus de cinq en trois mois, malgré les durcissements du noyau publiés entre-temps. Enfin, sur un échantillon de 166 exploits, les chercheurs ont relevé dix techniques d'exploitation inconnues d'eux et des experts tiers consultés. OpenAI ne publie ni les exploits ni ces techniques : les rapports partent vers les mainteneurs du noyau, en commençant par les failles critiques, puis progressivement via ses partenaires du programme Patch the Planet.

Le rapport reconnaît aussi ses limites. Lors d'un premier passage, 20 des 200 exploits déclarés réussis avaient obtenu root par une autre faille zero-day que celle qui leur était assignée : un contrôle indépendant a été ajouté. Environ 3,1 % des findings candidats provenaient d'une analyse erronée du modèle. Et chaque correctif proposé a été relu par des humains avant envoi aux mainteneurs.

Élévation de privilèges locale : de quoi parle-t-on

Une élévation de privilèges locale (LPE) est une vulnérabilité qui permet à un processus déjà présent sur la machine, lancé avec un compte ordinaire, d'obtenir les droits root en exploitant un bug du noyau. Elle ne s'exploite pas à distance : l'attaquant doit d'abord exécuter du code sur le serveur. C'est précisément ce qui rend ce type de faille trompeur. Sur un poste de travail, « l'utilisateur local » est une personne. Sur un serveur, c'est presque toujours un programme : l'application PHP derrière un site web, le processus d'un serveur de jeu qui charge des scripts tiers, un conteneur Docker, un runner d'intégration continue, un compte SSH prêté à un ami ou à un client.

Tant que les exploits LPE fiables restaient rares et coûteux à produire, une compromission limitée (un plugin malveillant, une injection de commande dans un formulaire) restait souvent confinée au compte touché. Le rapport d'OpenAI mesure un coût de production d'environ 359 $ par exploit sur une infrastructure d'agents. Cette barrière économique est en train de tomber, et les failles concernées vont être corrigées en public, dans le dépôt Git du noyau, où n'importe qui peut lire les correctifs. L'enjeu pour un administrateur de VPS n'est donc pas « vais-je être attaqué par OpenAI », mais « combien de temps mon serveur reste-t-il sans le correctif une fois celui-ci rendu public ».

Quels serveurs sont réellement exposés

La question à se poser est : quel code non maîtrisé tourne sur mon serveur, et sous quel compte ? Le tableau ci-dessous résume les situations les plus courantes chez les administrateurs de serveurs de jeu et de VPS.

Un point rassure les clients de VPS en virtualisation KVM : une LPE exploitée dans votre machine virtuelle donne root dans la VM, pas sur l'hôte physique. L'inverse vaut aussi : le noyau de votre VPS est le vôtre, c'est vous qui le mettez à jour et qui redémarrez. L'hébergeur maintient le noyau de l'hôte, vous maintenez celui de votre serveur.

La vague de correctifs qui arrive dans les distributions

Le chemin d'un correctif noyau est toujours le même. Il est d'abord fusionné dans la branche de développement principale (mainline), puis rétroporté par l'équipe stable de Greg Kroah-Hartman dans les branches stables et LTS maintenues, puis empaqueté par chaque distribution : Debian, Ubuntu, AlmaLinux, Rocky Linux, Proxmox VE. Depuis que le projet noyau attribue lui-même ses identifiants CVE, un numéro est attribué une fois le correctif disponible dans un arbre stable. Il faut donc s'attendre, dans les semaines qui viennent, à une série inhabituelle de CVE noyau, de versions stables rapprochées et de paquets linux-image ou kernel à installer.

Les chiffres du rapport donnent la mesure du reste à traiter : 61 failles corrigées upstream, 43 en staging, 299 signalées et discutées publiquement, et plus de 500 encore dans le circuit de signalement au moment de la publication. S'y ajoute un détail que le rapport souligne lui-même : seuls 7 % du code ont été analysés, et OpenAI prévoit de rescanner le code à mesure que ses modèles progressent et d'étendre la méthode à d'autres logiciels critiques.

État des branches du noyau publié sur kernel.org au 1er novembre 2026 :

Un correctif publié upstream n'est pas un correctif installé sur votre serveur. Entre les deux, il y a le rétroportage dans votre branche, l'empaquetage par votre distribution, l'installation du paquet et le redémarrage. Cette fenêtre est le vrai risque, et c'est la seule chose que vous contrôlez.

Choisir un noyau LTS et le tenir à jour

Commencez par identifier le noyau qui tourne réellement sur votre VPS ou votre serveur dédié, en SSH :

uname -r
cat /etc/os-release | head -n 2

Un noyau LTS ne contient pas moins de bugs qu'un noyau récent. Son avantage est ailleurs : les correctifs de sécurité y sont rétroportés pendant des années, par l'équipe stable puis par votre distribution, sans que vous ayez à changer de version majeure. Les branches stables non-LTS, comme la 7.2, ne vivent que quelques mois : la 7.2.15 du 1er novembre 2026 est la dernière, et tout serveur resté dessus ne recevra aucun des correctifs issus du rapport d'OpenAI. Un noyau compilé à la main depuis mainline pose le même problème : il faut le recompiler à chaque version.

En pratique, pour un serveur de production, utilisez le noyau fourni par votre distribution et vérifiez qu'il suit une branche maintenue. Debian 13 est livré avec un noyau 6.12 LTS, Debian 12 avec un 6.1 LTS. Sur Ubuntu LTS, Canonical rétroporte les correctifs de sécurité sur le noyau de la version, qu'il s'agisse du noyau GA ou du noyau HWE. Sur AlmaLinux et Rocky Linux, le numéro de version du paquet kernel ne change pas, mais les correctifs y sont rétroportés par Red Hat. Si vous hésitez encore sur la distribution d'un nouveau serveur, notre comparatif quelle distribution Linux pour un VPS détaille ces cycles de maintenance.

Pour lister les mises à jour de noyau en attente :

# Debian / Ubuntu
sudo apt update && apt list --upgradable 2>/dev/null | grep linux-image

# AlmaLinux / Rocky Linux
sudo dnf check-update kernel

Réduire la surface d'attaque locale : les user namespaces non privilégiés

Les user namespaces permettent à un processus sans privilège de créer un espace de noms dans lequel il devient « root », avec accès à des interfaces du noyau normalement réservées à l'administrateur : configuration réseau, montages, filtrage de paquets. C'est une fonctionnalité légitime, utilisée par les conteneurs sans privilège, Podman en mode rootless, les bacs à sable des navigateurs. C'est aussi, de longue date, une porte d'entrée privilégiée des chaînes d'exploitation du noyau : Canonical cite un rapport de Google selon lequel 44 % des exploits noyau observés nécessitaient des user namespaces non privilégiés. Le rapport d'OpenAI ne détaille pas quelles failles parmi les 948 passent par ce mécanisme, mais c'est le premier levier dont dispose un administrateur pour réduire la surface d'attaque exposée à un utilisateur local.

Sur Ubuntu 24.04 LTS et versions suivantes, la restriction est déjà active par défaut. Elle repose sur AppArmor : un processus non confiné peut créer un user namespace, mais n'y obtient aucune capacité supplémentaire, sauf si son profil AppArmor l'y autorise explicitement. Vérifiez que le réglage est bien en place :

sysctl kernel.apparmor_restrict_unprivileged_userns
# attendu : kernel.apparmor_restrict_unprivileged_userns = 1

Si la valeur est 0, un fichier dans /etc/sysctl.d/ l'a probablement désactivée pour faire fonctionner une application. Cherchez-le et évaluez si cette application a encore besoin de cette exception.

Sur Debian, AlmaLinux et Rocky Linux, il n'existe pas de médiation AppArmor équivalente. Le réglage disponible est le paramètre upstream user.max_user_namespaces, qui fixe le nombre maximal de user namespaces qu'un utilisateur peut créer. Le mettre à zéro interdit leur création :

sysctl user.max_user_namespaces
echo "user.max_user_namespaces = 0" | sudo tee /etc/sysctl.d/90-userns.conf
sudo sysctl --system

Ce réglage est tout ou rien : il s'applique aussi aux processus lancés par root. Ne l'appliquez pas sans vérifier ce qui en dépend sur votre serveur :

• Docker en mode classique (démon root, sans userns-remap) continue de fonctionner : il n'a pas besoin de user namespaces.
• Docker rootless et Podman rootless cessent de fonctionner : ils reposent entièrement sur les user namespaces. Voir notre comparatif Podman ou Docker sur VPS Linux.
• Conteneurs LXC non privilégiés (Proxmox VE, Incus, LXD) cessent de démarrer : leur isolation est précisément construite sur ce mécanisme. Sur un hôte Incus ou Proxmox, laissez ce réglage tranquille et concentrez-vous sur la mise à jour du noyau hôte.
• Certains services systemd utilisant PrivateUsers=, les paquets Snap ou Flatpak et les navigateurs en bac à sable peuvent aussi être affectés.

Sur un VPS qui n'héberge qu'un serveur de jeu lancé directement sur l'hôte, un serveur web ou une base de données, la désactivation est généralement sans effet visible et retire d'un coup une grande partie de la surface d'attaque locale du noyau. Testez d'abord sur un serveur de préproduction, puis surveillez les journaux quelques jours.

Conteneurs Docker et nodes Pterodactyl : le noyau est partagé

Un conteneur n'est pas une machine virtuelle. Tous les conteneurs d'un hôte, qu'ils soient lancés par Docker, Podman ou le démon Wings de Pterodactyl, exécutent leurs processus sur le même noyau que l'hôte. Une élévation de privilèges noyau réussie depuis l'intérieur d'un conteneur donne donc root sur l'hôte et, par ricochet, sur tous les autres conteneurs. Sur un node Pterodactyl qui héberge des dizaines de serveurs de jeu appartenant à des clients différents, c'est le scénario à éviter en priorité.

Docker réduit cette exposition par deux mécanismes qu'il faut conserver. Son profil seccomp par défaut interdit à un conteneur la création de nouveaux namespaces par les appels système clone et unshare tant que le conteneur ne possède pas la capacité CAP_SYS_ADMIN, et il filtre des dizaines d'autres appels système rarement nécessaires. Et par défaut, un conteneur démarre avec un jeu de capacités réduit. Trois réflexes en découlent :

• Ne lancez jamais un serveur de jeu ou une application avec --privileged : l'option donne toutes les capacités au conteneur, et le profil seccomp s'adapte aux capacités accordées. Le conteneur retrouve alors presque tous les droits de l'hôte.
• N'ajoutez pas --cap-add SYS_ADMIN ni --security-opt seccomp=unconfined pour « faire marcher » une image : cherchez la cause réelle.
• Faites tourner le processus du conteneur sous un utilisateur non root. Les images Pterodactyl le font déjà ; votre propre Dockerfile doit définir un USER. Pour un serveur FiveM conteneurisé, suivez notre guide FiveM sous Docker sur VPS Linux.

Sur un serveur dédié de virtualisation, la distinction entre conteneur et machine virtuelle devient un choix de sécurité. Un conteneur LXC sous Proxmox VE ou Incus partage le noyau de l'hôte ; une VM KVM embarque le sien. Pour héberger un locataire que vous ne connaissez pas ou un serveur de jeu qui charge des scripts d'origine incertaine, la VM isole mieux contre ce type précis de faille. Notre guide sécuriser et mettre à jour Proxmox VE détaille la procédure de mise à jour du noyau hôte, et l'actualité sur la faille critique LXD et MicroCloud rappelle que la couche de gestion des conteneurs est elle aussi une cible.

Mises à jour automatiques et redémarrages planifiés

Un correctif noyau ne prend effet qu'après un redémarrage. Installer le paquet sans redémarrer laisse le serveur exactement aussi vulnérable qu'avant, avec en prime l'illusion d'être protégé. Avec une vague de correctifs qui va s'étaler sur plusieurs semaines, la seule approche tenable est d'automatiser l'installation et de planifier les redémarrages dans une fenêtre où ils dérangent le moins.

Sur Debian et Ubuntu, unattended-upgrades installe les mises à jour de sécurité sans intervention. Notre guide automatiser les mises à jour de sécurité sur un VPS Ubuntu couvre l'installation et les contrôles. Pour que le redémarrage suive, ajoutez dans /etc/apt/apt.conf.d/50unattended-upgrades :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";

Le redémarrage n'a lieu que si le fichier /var/run/reboot-required existe après une mise à jour, c'est-à-dire quand un paquet, le plus souvent le noyau, l'exige. Par défaut, il est reporté si un utilisateur est connecté, sauf avec Unattended-Upgrade::Automatic-Reboot-WithUsers "true";. Pour vérifier à tout moment si votre serveur attend un redémarrage :

# Debian / Ubuntu
test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs

# AlmaLinux / Rocky Linux
sudo dnf needs-restarting -r

Pour un serveur FiveM, Minecraft ou Rust, choisissez l'heure de redémarrage au creux de fréquentation, annoncez-la aux joueurs et assurez-vous que le serveur de jeu est déclaré comme service systemd activé au démarrage, sinon il ne reviendra pas tout seul. Sur un node Pterodactyl, le redémarrage de l'hôte interrompt tous les serveurs du node : planifiez-le et contrôlez ensuite que Wings et chaque serveur ont bien redémarré. Avant la première mise à jour de noyau, faites une sauvegarde rsync vers un serveur distant : un noyau qui ne démarre pas se rattrape depuis le menu GRUB en console, mais une sauvegarde évite de le faire sous pression.

Surveiller les tentatives d'exploitation

Un exploit noyau qui échoue laisse souvent des traces : une erreur BUG:, un general protection fault ou un avertissement dans le journal du noyau. Consultez-les régulièrement :

sudo journalctl -k -p warning --since "24 hours ago"

Avec auditd, vous pouvez journaliser toute création de namespace par un compte non système, ce qu'un serveur web ou un serveur de jeu n'a normalement aucune raison de faire :

-a always,exit -F arch=b64 -S unshare -F auid>=1000 -k userns

Complétez avec une surveillance des ressources : un processus inconnu, une charge CPU sans rapport avec l'activité des joueurs ou un binaire lancé depuis /tmp sont des signaux à prendre au sérieux. Notre guide sur l'analyse des journaux d'un serveur de jeu avec journalctl donne les filtres utiles.

Checklist pour l'administrateur

1. Identifiez votre noyau avec uname -r et vérifiez qu'il suit une branche maintenue (LTS ou stable courante). Quittez la branche 7.2, en fin de vie.
2. Listez ce qui exécute du code sous un compte local : serveurs de jeu et leurs scripts, applications web, conteneurs, comptes SSH tiers.
3. Sur Ubuntu 24.04 et suivants, confirmez que kernel.apparmor_restrict_unprivileged_userns vaut 1. Sur Debian ou RHEL sans conteneurs non privilégiés, envisagez user.max_user_namespaces = 0 après test.
4. Sur Docker et Pterodactyl, bannissez --privileged, seccomp=unconfined et CAP_SYS_ADMIN ; vérifiez que les processus tournent sous un utilisateur non root.
5. Activez les mises à jour de sécurité automatiques et un redémarrage planifié dans une fenêtre creuse ; déclarez vos serveurs de jeu en services systemd.
6. Durcissez SSH (clés uniquement, pas de root direct) et appliquez les premiers réglages de sécurisation : la LPE n'est que la seconde étape d'une attaque, rendez la première difficile.
7. Surveillez le journal noyau et les créations de namespaces, et suivez les bulletins de sécurité de votre distribution dans les semaines à venir. La faille Fragnesia d'octobre a montré à quelle vitesse un correctif noyau public devient un exploit en circulation.

Conclusion

Le rapport d'OpenAI ne révèle pas une faille, il révèle un changement d'échelle : 948 chemins vers root trouvés en quelques jours dans 7 % du noyau Linux, pour un coût de quelques centaines de dollars par exploit, et une méthode que son auteur annonce vouloir rejouer. Pour un administrateur de VPS Linux ou de serveur dédié, la réponse tient en quatre décisions : un noyau sur une branche maintenue, des user namespaces non privilégiés restreints là où rien n'en dépend, des conteneurs qui gardent seccomp et leurs capacités réduites, et des mises à jour qui se terminent par un redémarrage planifié plutôt que par un paquet installé en attente. Le reste, les correctifs eux-mêmes, arrive par le canal habituel de votre distribution. Il suffit de ne pas le laisser attendre.