Un exploit public visant AF_UNIX brise l’isolation des conteneurs Ubuntu et atteint les privilèges root de l’hôte

Un exploit public visant CVE-2026-80521 peut transformer une exécution de code limitée dans un conteneur Ubuntu en privilèges root sur l’hôte sous-jacent.

La vulnérabilité est un use-after-free affectant le garbage collector des sockets AF_UNIX du noyau Linux. Elle est exploitable au moyen d’appels système ordinaires autorisés par les configurations seccomp standard de Docker et Kubernetes, ce qui rend les contrôles par défaut des conteneurs inefficaces contre cette voie d’attaque.

DepthFirst a publié un code d’exploitation fonctionnel ciblant Ubuntu 26.04. Au 23 septembre 2026, aucune attaque n’a été confirmée et la vulnérabilité ne figure pas dans le catalogue des vulnérabilités exploitées connues de la Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis. Il n’existe donc aucune échéance de remédiation fixée par la CISA.

La publication de cet exploit accroît néanmoins le risque pour les plateformes qui exécutent des conteneurs non fiables ou semi-fiables sur un noyau partagé.

Une condition de concurrence dans le garbage collector AF_UNIX ouvre la voie à l’évasion

Les sockets AF_UNIX fournissent un mécanisme de communication interprocessus local et permettent de transférer des descripteurs de fichiers ouverts au moyen de messages SCM_RIGHTS. Le noyau doit suivre ces références transférées et récupérer les groupes circulaires de sockets qui ne sont plus accessibles.

CVE-2026-80521 découle d’une condition de concurrence au sein de ce processus de garbage collection.

Ubuntu attribue le signalement à Kyle Zeng. Sa description technique utilise trois sockets — A, B et X — pour expliquer le déroulement de cette condition de concurrence :

1. Les sockets A et B appartiennent à des groupes de références liés, appelés composantes fortement connexes (strongly connected components ou SCC), tandis que X est associé au groupe.
2. Des opérations concurrentes envoient sk-B depuis sk-X vers sk-B, puis ferment A et B.
3. Pendant l’opération d’envoi, unix_add_edges() publie une nouvelle arête représentant la relation B vers B.
4. Un intervalle très court s’écoule avant que le tampon de socket contenant cette référence soit ajouté au moyen de skb_queue_tail().
5. Si les opérations de fermeture et le garbage collection interviennent pendant cet intervalle, le collecteur peut classer le groupe A-B comme inactif.
6. B n’est pas immédiatement libéré, car le collecteur ne peut pas encore voir le tampon de socket contenant la référence nouvellement publiée.
7. Lors d’un passage ultérieur, le collecteur suit le scc_entry obsolète de B jusqu’à une zone de mémoire partiellement libérée.

Il en résulte un use-after-free. La correction en amont, intitulée af_unix: Unlink scc_entry in unix_del_edge()., supprime l’entrée SCC interne avant de libérer le vertex qui lui est associé.

L’explication de DepthFirst aboutit à la même conclusion fondamentale : le collecteur peut observer une référence publiée avant de voir la structure de données qui la contient. Le nettoyage partiel laisse alors un pointeur persistant orienté vers une zone de mémoire libérée.

Les contrôles par défaut des conteneurs ne bloquent pas les appels nécessaires

La vulnérabilité ne nécessite pas d’accès distant à l’hôte. L’attaquant doit disposer d’un contexte d’exécution local faiblement privilégié, par exemple du contrôle d’un processus à l’intérieur d’un conteneur.

Cette exigence se reflète dans le score CVSS élevé de 7,8 et dans le vecteur suivant :

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

L’attaque est peu complexe, nécessite peu de privilèges et ne requiert aucune interaction de l’utilisateur. Une exploitation réussie peut compromettre la confidentialité, l’intégrité et la disponibilité de l’hôte.

Les opérations sur les sockets AF_UNIX sont généralement disponibles à l’intérieur des conteneurs. Les profils seccomp de Docker et Kubernetes autorisent par défaut les interfaces concernées ; l’exploit ne dépend donc pas d’une configuration inhabituelle ou délibérément permissive.

Une fois la faille de mémoire du noyau exploitée, les namespaces, les cgroups et les filtres seccomp ne peuvent plus préserver la frontière de sécurité prévue. Ces mécanismes isolent les processus tout en s’appuyant sur le même noyau hôte. Une compromission du noyau intervient à un niveau inférieur.

Cette distinction est importante pour les services multitenants, les runners CI/CD, les environnements de développement fondés sur des conteneurs et les systèmes qui exécutent du code fourni par des clients. Un processus qui devrait être confiné à un seul conteneur peut au contraire obtenir le contrôle root de l’hôte et potentiellement affecter les autres charges de travail qui le partagent.

L’exposition d’Ubuntu dépend du paquet de noyau installé

Le suivi de sécurité au niveau des paquets d’Ubuntu fournit une évaluation plus précise que le seul numéro de version du système d’exploitation.

Le paquet de base linux d’Ubuntu 22.04 LTS est indiqué comme non affecté. En revanche, le paquet linux-hwe-6.8 de cette même version est vulnérable. Les administrateurs doivent donc vérifier la variante du noyau et la branche de paquets effectivement installées.

Les statuts publiés pertinents sont les suivants :

Paquet	Version Ubuntu	Statut
linux	26.04 LTS, Resolute	Vulnérable, correction en cours
linux	24.04 LTS, Noble	Vulnérable
linux	22.04 LTS, Jammy	Non affecté
linux-hwe-6.8	22.04 LTS, Jammy	Vulnérable
linux-hwe-6.17	24.04 LTS, Noble	Vulnérable
linux-hwe-7.0	24.04 LTS, Noble	Vulnérable
linux-aws	26.04 LTS, Resolute	Vulnérable
linux-aws	24.04 LTS, Noble	Vulnérable
linux-aws	22.04 LTS, Jammy	Non affecté
linux-aws-6.8	22.04 LTS, Jammy	Vulnérable
linux-aws-7.0	26.04 LTS, Resolute	Vulnérable
linux-azure	26.04 LTS, Resolute	Vulnérable
linux-azure	24.04 LTS, Noble	Vulnérable
linux-azure	22.04 LTS, Jammy	Non affecté
linux-azure-6.8	22.04 LTS, Jammy	Vulnérable

Plusieurs branches anciennes ou remplacées sont indiquées comme non affectées, non publiées, ignorées ou en fin de vie. C’est notamment le cas de linux-kvm sur Ubuntu 22.04, 20.04 et 18.04, ainsi que des branches AWS, Azure et HWE 5.15 sur Ubuntu 20.04.

L’avis Ubuntu disponible ne fournit aucun statut pour un paquet spécifique à GCP. Il n’indique pas non plus de date pour la publication de builds Ubuntu corrigés.

Un correctif en amont existe, mais la remédiation Ubuntu reste incomplète

Le code vulnérable du noyau a été introduit dans Linux 6.10, puis rétroporté vers les branches stables 6.1 et 6.6.

Le correctif en amont a été intégré le 6 août à la branche principale du noyau 7.2 et au noyau stable 7.1.10. Les organisations qui maintiennent des noyaux personnalisés peuvent appliquer directement cette modification, sous réserve de leurs processus habituels de test et de déploiement.

La disponibilité de ce correctif en amont ne signifie pas que toutes les branches de noyau Ubuntu ont reçu un paquet corrigé. Ubuntu identifie toujours plusieurs branches comme vulnérables, le paquet linux de base d’Ubuntu 26.04 étant précisément indiqué comme faisant l’objet d’une remédiation en cours.

Aucune mesure de contournement temporaire n’a été publiée par Ubuntu ou DepthFirst. Aucun indicateur d’exploitation, artefact forensique ou indicateur fiable au niveau du noyau permettant aux défenseurs d’identifier une tentative d’exploitation n’a non plus été divulgué.

Une recherche assistée par l’IA a produit un exploit fonctionnel du noyau

DepthFirst a indiqué que son modèle de détection des vulnérabilités, dfs-large1, avait identifié la faille avec l’aide d’un harnais de test piloté par un humain. L’entreprise a utilisé l’exploit pour remporter une place dans le kernelCTF de Google le 24 juillet, puis a signalé le problème à l’équipe de sécurité du noyau le 5 août.

Les mainteneurs du noyau ont ensuite informé DepthFirst qu’un chercheur d’OpenAI avait découvert indépendamment la même faille. Le commit associé au CVE crédite Kyle Zeng comme découvreur.

Cet épisode illustre davantage qu’un simple triage automatisé des bugs. Le processus de recherche a abouti à une évasion de conteneur fonctionnelle contre Ubuntu 26.04, couvrant la découverte, l’analyse de la condition de concurrence, l’exploitation et la validation sur une cible concrète.

Il s’inscrit également dans la continuité d’autres vulnérabilités du noyau découvertes dans le cadre de recherches assistées par l’IA et permettant une élévation des privilèges jusqu’au root de l’hôte. La disponibilité publique d’exploits est devenue un problème opérationnel récurrent pour les hôtes Linux non corrigés, et non plus seulement un indicateur de gravité théorique.

Les défenseurs doivent donner la priorité à l’inventaire des noyaux et à une isolation renforcée

Les administrateurs doivent commencer par associer chaque hôte de conteneurs au paquet et à la branche de noyau installés. Vérifier uniquement qu’une machine exécute Ubuntu 22.04, 24.04 ou 26.04 ne suffit pas, car les paquets de base, HWE, AWS et Azure présentent des statuts différents.

Lorsque cela est possible, les noyaux personnalisés affectés doivent recevoir le correctif en amont. Les systèmes gérés par Ubuntu doivent installer les paquets de distribution corrigés dès leur publication.

D’ici là, les organisations devraient réévaluer les charges de travail autorisées à partager un même noyau. DepthFirst recommande une isolation fondée sur des microVM, comme Firecracker ou Kata Containers, pour l’exécution de code non fiable. Ces architectures fournissent aux charges de travail des noyaux distincts, empêchant un exploit du noyau d’un conteneur de compromettre directement le noyau principal de l’hôte.

La surveillance doit se concentrer sur les processus inattendus au niveau de l’hôte provenant de contextes de conteneurs, les changements de privilèges inexpliqués et les modifications non autorisées de fichiers de l’hôte ou de la configuration du runtime. Il s’agit de signaux comportementaux, et non d’indicateurs propres à cette vulnérabilité.

L’absence d’attaques confirmées ou de référencement dans le catalogue KEV de la CISA ne doit pas être interprétée comme le signe d’une faible exploitabilité. Un code fonctionnel est déjà public et les interfaces concernées sont exposées dans les configurations standard des conteneurs.