Une faille du noyau Linux permet encore de sortir d’un conteneur Ubuntu, exploit public à l’appui
Corrigée en amont le 6 août 2026 dans le noyau Linux, CVE-2026-80521 reste non corrigée dans Ubuntu 26.04, 24.04 et 22.04 LTS, et la société DepthFirst a publié un exploit de sortie de conteneur le 22 septembre. Si vous hébergez des charges non fiables, appliquez le correctif amont ou isolez-les dans des microVMs.
6 août 2026. Le correctif de CVE-2026-80521 est intégré en amont dans le noyau Linux 7.2 et la branche stable 7.1.10. 22 septembre 2026. DepthFirst publie une recherche et un exploit de sortie de conteneur ciblant Ubuntu 26.04. 23 septembre 2026. Le tracker de sécurité d’Ubuntu liste toujours le paquet noyau comme « vulnerable, work in progress ». Pourquoi c’est important : la faille est corrigée en amont depuis six semaines, mais aucune distribution Ubuntu LTS n’a encore reçu le correctif — et un exploit public existe désormais.
Un use-after-free dans le ramasse-miettes des sockets AF_UNIX
La faille se niche dans le ramasse-miettes du sous-système AF_UNIX du noyau. Ce collecteur nettoie les descripteurs de fichiers passés entre processus via les messages SCM_RIGHTS. Les sockets AF_UNIX assurent la communication locale entre processus et sont autorisées par défaut dans les profils seccomp de Docker et de Kubernetes — c’est précisément ce qui rend la faille atteignable depuis l’intérieur d’un conteneur.
Le défaut est une course (race condition). Le collecteur peut apercevoir de nouvelles références avant que les données qui les portent soient mises en file d’attente. S’il s’exécute dans cette fenêtre, il libère une partie d’un groupe de sockets liés sans retirer un pointeur d’une liste interne persistante. Le passage suivant suit ce pointeur vers de la mémoire libérée — un use-after-free classique.
La conséquence est lourde : l’exploit atteint le noyau par des appels système ordinaires que les conteneurs sont autorisés à effectuer. Il contourne donc l’isolation par namespaces, les limites de cgroups et le filtrage seccomp. DepthFirst démontre une sortie de conteneur vers un root sur l’hôte, avec un exploit ciblant Ubuntu 26.04.
Corrigé en amont, pas encore chez Ubuntu
Le calendrier est le cœur du problème. La faille a été corrigée le 6 août 2026 dans le noyau principal 7.2 et la branche stable 7.1.10. Le code vulnérable a été introduit dans le noyau 6.10 et rétroporté vers les branches stables 6.1 et 6.6.
Mais le tracker de sécurité d’Ubuntu liste toujours le paquet Linux de 26.04 comme « vulnerable, work in progress », sans date de publication pour la mise à jour de distribution. Les versions 24.04 et 22.04 sont également touchées, via des paquets noyau plus récents — y compris ceux destinés aux charges AWS, Azure et GCP. Autrement dit, aucune des trois LTS ne propose aujourd’hui de correctif.
La faille n’est pas dans le catalogue KEV de la CISA et aucune attaque en conditions réelles n’est confirmée. Mais la publication d’un exploit par DepthFirst change l’équation : la barrière n’est plus la compétence, mais le temps que mettra l’attaquant à l’adapter.
Une faille découverte par un modèle d’IA, confirmée par un humain
La genèse de CVE-2026-80521 illustre la bascule en cours dans la recherche de vulnérabilités. DepthFirst indique que son modèle dfs-large1, entraîné à la détection de vulnérabilités, a trouvé la faille aux côtés d’un harnais de test piloté par un humain. L’entreprise a remporté un slot Google kernelCTF avec l’exploit le 24 juillet et signalé le bug à l’équipe de sécurité du noyau le 5 août.
Les mainteneurs ont répondu qu’un chercheur d’OpenAI avait signalé indépendamment le même bug. Le commit du CVE crédite le chercheur Kyle Zeng comme rapporteur. Ce n’est pas un cas isolé : une faille futex divulguée en juillet et une faille du sous-système cryptographique en avril permettaient déjà à un utilisateur non privilégié d’escalader vers root sur l’hôte, deux découvertes impliquant de la recherche assistée par IA.
Le constat de DepthFirst est tranché : la découverte assistée par IA a abaissé la barrière à un point tel qu’on ne peut plus traiter les conteneurs comme une frontière de sécurité. « La barrière pour sortir d’un conteneur en attaquant le noyau a tellement baissé que nous devons partir du principe que les attaquants peuvent le faire à volonté. » Le chiffre qui appuie ce constat : près de 5 700 CVE du noyau Linux publiées en 2026, un record annuel selon LinuxCVETracker.
Le programme kernelCTF de Google mérite une ligne : c’est un programme de primes qui récompense la démonstration d’exploits contre le noyau Linux, pensé pour faire remonter les bugs avant les attaquants. Qu’une entreprise comme DepthFirst y gagne un slot avec un bug trouvé par un modèle d’IA est le signe que la détection automatisée atteint un niveau opérationnel — et que le rythme de publication des CVE du noyau, déjà record, ne va pas ralentir.
Ce que vous pouvez faire aujourd’hui
La parade dépend de votre niveau d’exposition. Les organisations qui font tourner un noyau affecté peuvent appliquer le correctif amont directement — c’est la seule voie immédiate tant qu’Ubuntu n’a pas publié sa mise à jour.
# Vérifier la version du noyau en cours d'exécution
uname -r
# Vérifier si le correctif amont « unix_del_edge » est présent dans votre arbre
grep -R "unix_del_edge" /lib/modules/$(uname -r)/build/net/unix/ 2>/dev/null || \
echo "Correctif non détecté localement — vérifier auprès de votre distribution"Ni DepthFirst ni Ubuntu n’ont publié de contournement temporaire. La recommandation de DepthFirst est structurelle : déplacer les charges non fiables vers une isolation par microVM — Firecracker ou Kata Containers — qui donne à chaque charge son propre noyau au lieu de partager celui de l’hôte. C’est un changement d’architecture, pas un patch, mais c’est la seule réponse durable à une série de failles de sortie de conteneur qui se répète depuis le début de l’année.
Comment vérifier votre exposition
Le premier réflexe est de savoir quel noyau vous faites tourner, puis de le comparer aux plages affectées. Le code vulnérable a été introduit dans le noyau 6.10 et rétroporté vers les branches stables 6.1 et 6.6. En pratique, cela signifie que la plupart des noyaux récents — y compris ceux d’Ubuntu, de Debian et des distributions qui suivent ces branches — sont concernés tant qu’ils n’ont pas intégré le correctif amont.
Pour les déploiements Kubernetes ou Docker, la question ne se pose pas au niveau du conteneur : c’est le noyau partagé de l’hôte qui est en cause. Un nœud vulnérable expose tous les pods qu’il héberge, indépendamment de la politique réseau ou des quotas de ressources. La mise à jour doit donc se faire sur l’image de la machine hôte, pas dans le conteneur. Sur les charges managées (AWS, Azure, GCP), le correctif dépend du fournisseur, ce qui allonge encore la fenêtre quand l’éditeur de distribution tarde.
Le suivi est simple à mettre en place : surveiller le tracker de sécurité Ubuntu pour le paquet Linux, et appliquer le correctif amont à la première disponibilité. Les équipes qui ne peuvent pas attendre ont une voie documentée — appliquer le correctif du noyau amont directement, en le testant d’abord sur un environnement non critique. Ni DepthFirst ni Ubuntu n’ont publié de contournement plus léger.
Verdict
CVE-2026-80521 n’est pas la faille la plus grave de 2026 — CVSS 7,8, pas d’exploitation confirmée — mais elle est la plus démonstrative d’un basculement. Si vous hébergez du code non fiable dans des conteneurs sur Ubuntu, vous avez deux options immédiates : appliquer le correctif amont, ou migrer ces charges vers des microVMs. Si vos conteneurs n’exécutent que votre propre code, le risque est contenu, mais la fenêtre se referme vite : un exploit public circule déjà, et Ubuntu n’a pas annoncé de date.