Table des matières de l'article :
CVE-2026-23111 est une vulnérabilité du noyau Linux, plus précisément du sous-système Netfilter/nf_tables, qui permet, sous certaines conditions, à un utilisateur local non privilégié d'obtenir les privilèges root. Il ne s'agit pas d'une vulnérabilité d'accès distant exploitable directement sur un réseau, mais d'une faille d'élévation de privilèges locale . Ce type de vulnérabilité peut être exploité par un attaquant ayant déjà obtenu un accès limité au système : un shell utilisateur, l'exécution de code via une application web compromise ou une intrusion dans un conteneur.
L'histoire est intéressante car le bug provient d'une condition logique inversée : un seul caractère, le symbole !, modifie le comportement attendu du code et ouvre la voie à une utilisation-après-libre au niveau du noyau. Concrètement, le problème affecte les systèmes Linux qui exposent simultanément nf_tables e user namespaces, une combinaison assez courante sur de nombreuses distributions modernes.
Pour les hébergeurs, les administrateurs système Linux et toute personne gérant des serveurs mutualisés, des hôtes de conteneurs, des environnements CI/CD, des nœuds Kubernetes, des VPS ou des serveurs accessibles via shell, cette vulnérabilité (CVE) mérite une attention immédiate. Le risque ne réside pas tant dans une attaque directe depuis l'extérieur, mais plutôt dans la possibilité qu'une compromission initiale relativement limitée puisse mener à un contrôle total du système.
Qu'est-ce que nf_tables et pourquoi est-ce impliqué ?
nf_tables est le framework moderne du noyau Linux utilisé par nftablesSuccesseur d'iptables, d'ip6tables, d'arptables et d'ebtables, ce composant permet de définir des règles de filtrage, de NAT, de manipulation et de classification du trafic réseau. Même si l'administrateur n'utilise pas directement la commande nft, le sous-système peut être présent et utilisé indirectement par les gestionnaires de pare-feu, les environnements d'exécution de conteneurs, les orchestrateurs ou les outils système.
La vulnérabilité CVE-2026-23111 affecte une fonction spécifique, nft_map_catchall_activate()Ce système gère les éléments « catchall » des tables nftables lors de l'annulation d'une transaction. nftables fonctionne selon un modèle transactionnel : les modifications de règles sont préparées, puis appliquées ou annulées. En cas de problème, le noyau doit rétablir correctement les éléments temporairement désactivés.
Le problème est que, dans ce cas précis, la logique a été inversée. La fonction aurait dû ignorer les éléments déjà actifs et réactiver les inactifs. Or, à cause d'une négation incorrecte, elle a fait l'inverse : elle a ignoré les éléments inactifs et traité les actifs. La correction en amont est conceptuellement minimale :
- if (!nft_set_elem_active(ext, genmask))
+ if (nft_set_elem_active(ext, genmask))
continue;
Il s'agit d'un exemple classique où une modification apparemment anodine du code source du noyau peut avoir de graves conséquences en matière de sécurité. Le code vulnérable peut entraîner une gestion incorrecte des références internes au sein des chaînes de nftables ; en répétant certaines opérations, le compteur de références peut être décrémenté incorrectement jusqu'à ce qu'une structure encore référencée puisse être libérée. C'est là qu'intervient l'utilisation après libération (use-after-free) , l'une des catégories de bogues du noyau les plus dangereuses.
Utilisation de mémoire après libération dans le noyau : pourquoi c’est grave
Une attaque par utilisation après libération (use-after-free) se produit lorsqu'un logiciel continue d'utiliser une zone de mémoire après l'avoir libérée. Dans l'espace utilisateur, cela peut déjà constituer un problème important ; au niveau du noyau, c'est beaucoup plus grave, car le noyau est le composant le plus privilégié du système d'exploitation. Si un attaquant parvient à influencer la réutilisation de cette mémoire, il peut corrompre des structures internes, détourner le flux d'exécution ou manipuler les identifiants et les privilèges.
Dans le cas de la CVE-2026-23111, la faille devient exploitable lorsqu'un utilisateur non privilégié accède au code vulnérable grâce à la combinaison des espaces de noms utilisateur et des nftables . Les espaces de noms utilisateur permettent à un processus non privilégié d'apparaître comme administrateur (root) au sein d'un espace de noms isolé. Cette fonctionnalité est utile pour les conteneurs sans privilèges root, les environnements sandbox, les environnements isolés et certaines technologies de bureau, mais elle augmente également la surface d'attaque du noyau.
L'essentiel est le suivant : même sans privilèges root sur l'hôte, un utilisateur isolé dans un espace de noms peut acquérir les capacités nécessaires pour interagir avec des parties du noyau normalement inaccessibles. Si l'une de ces parties présente une vulnérabilité, l'isolation peut permettre une élévation de privilèges.
Il ne s'agit pas d'une exécution de code à distance, mais il ne faut pas la sous-estimer.
Il est important d'éviter toute fausse alerte : la vulnérabilité CVE-2026-23111 ne correspond pas à une attaque d'exécution de code à distance directement accessible depuis Internet. Un serveur n'est pas compromis simplement parce qu'un port est ouvert. Cependant, en matière de sécurité Linux, les vulnérabilités locales sont souvent cruciales après une intrusion.
Un attaquant peut initialement obtenir un accès limité via une application web vulnérable, un plugin WordPress compromis, des identifiants SSH faibles, une clé volée, un processus conteneurisé ou un service exécuté avec des privilèges réduits. L'élévation de privilèges locale lui permet ensuite de passer d'un compte utilisateur limité à l'accès root, rendant ainsi la maîtrise de l'incident beaucoup plus difficile.
C’est pourquoi cette vulnérabilité doit être considérée comme particulièrement pertinente dans les scénarios suivants :
- Serveur d'hébergement partagé avec plusieurs utilisateurs locaux ;
- serveurs avec accès SSH accordé aux clients, développeurs ou fournisseurs ;
- Hôte de conteneurs Docker, Podman, LXC ou Kubernetes ;
- Exécuteurs CI/CD qui compilent ou testent du code qui n'est pas entièrement fiable ;
- environnements multi-locataires ;
- serveurs web où une compromission d'application pourrait fournir un accès limité ;
- systèmes avec espaces de noms utilisateur activés pour les utilisateurs non privilégiés.
Sur un serveur traditionnel, sans utilisateurs locaux non fiables ni conteneurs sans privilèges, l'urgence est moindre, mais le noyau doit tout de même être mis à jour. Dans un contexte professionnel, il est déconseillé de laisser une vulnérabilité connue du noyau, dont les détails techniques sont publics, sans solution immédiate.
Distributions concernées et état des correctifs
La vulnérabilité a été corrigée en amont dans le noyau Linux et est référencée publiquement sous la référence CVE-2026-23111 dans la base de données nationale des vulnérabilités ( NVD). Ubuntu la classe comme une vulnérabilité prioritaire, décrivant explicitement la possibilité d'une élévation de privilèges locale via les espaces de noms utilisateur et les nftables. Debian la suit dans son outil de suivi de sécurité , avec des versions corrigées pour les branches prises en charge.
Dans l'univers Enterprise Linux, AlmaLinux a intégré la vulnérabilité CVE dans ses mises à jour du noyau. Plus précisément, pour AlmaLinux 9, elle est présente dans l'avis de sécurité ALSA-2026:6570 , tandis que pour AlmaLinux 10, elle est présente dans l'avis de sécurité ALSA-2026:18134 . Les distributions Rocky Linux et dérivées de RHEL intègrent également ce correctif dans leurs mises à jour de paquets du noyau.
Le conseil opérationnel est simple : ne tentez pas de modifier manuellement le code source du noyau sur les serveurs de production. Installez le noyau approprié fourni par le fournisseur de votre distribution et redémarrez le système pour utiliser ce nouveau noyau.
Comment vérifier rapidement votre système
La première vérification concerne la version du noyau actuellement en cours d'exécution :
uname -r
Cette commande affiche le noyau réellement démarré, et non simplement le dernier noyau installé. Cette distinction est cruciale : après une mise à jour du noyau, le système reste vulnérable jusqu’à ce qu’il redémarre sur le noyau correct.
Pour vérifier si les modules nftables sont présents ou chargés :
lsmod | grep -E 'nf_tables|nft'
Pour vérifier les options de configuration du noyau :
zgrep -E 'CONFIG_USER_NS|CONFIG_NF_TABLES' /proc/config.gz 2>/dev/null || \
grep -E 'CONFIG_USER_NS|CONFIG_NF_TABLES' /boot/config-$(uname -r)
Si le système expose les deux CONFIG_USER_NS que CONFIG_NF_TABLESLa machine doit être considérée comme potentiellement exposée, à moins que le fournisseur n'ait déjà fourni un correctif appliqué et que le serveur n'ait été redémarré sur le noyau correct.
Sur AlmaLinux, Rocky Linux, RHEL et dérivés, il est également utile de vérifier la valeur de user.max_user_namespaces:
sysctl user.max_user_namespaces
Une valeur supérieure à zéro indique que le système autorise la création d'espaces de noms utilisateur jusqu'à la limite configurée. Une valeur égale à zéro désactive la création d'espaces de noms utilisateur.
Comment appliquer des correctifs à AlmaLinux, Rocky Linux et aux distributions de type RHEL ?
Sur AlmaLinux et les systèmes Enterprise Linux compatibles, la procédure recommandée consiste à mettre à jour les paquets du noyau via dnf:
dnf clean all
dnf update -y 'kernel*'
reboot
Après le redémarrage, vérifiez à nouveau le noyau en cours d'exécution :
uname -r
rpm -q kernel kernel-core kernel-modules
Pour déterminer si un redémarrage est toujours nécessaire après la mise à jour, vous pouvez utiliser :
dnf install -y yum-utils
needs-restarting -r
Si la commande indique qu'un redémarrage du système est nécessaire, cela signifie que le noyau mis à jour n'est pas encore en cours d'exécution. Dans un contexte serveur, notamment pour l'hébergement ou l'hébergement de conteneurs, cette étape est indispensable : la mise à jour des paquets RPM sans redémarrage ne supprime pas les risques.
Mesure d'atténuation temporaire : désactiver les espaces de noms utilisateur
Lorsqu'un redémarrage immédiat est impossible, une solution efficace consiste à désactiver la création d'espaces de noms utilisateur par les utilisateurs non privilégiés. Sur AlmaLinux, Rocky Linux et les systèmes de type RHEL, la méthode appropriée consiste à utiliser le paramètre user.max_user_namespaces:
cat > /etc/sysctl.d/99-disable-userns.conf <<'EOF'
user.max_user_namespaces = 0
EOF
sysctl --system
La vérification est effectuée avec :
sysctl user.max_user_namespaces
Le résultat attendu est :
user.max_user_namespaces = 0
Cette mesure d'atténuation réduit la surface d'attaque en empêchant les utilisateurs non privilégiés de créer des espaces de noms utilisateur. Cependant, il ne s'agit pas d'un correctif ; elle permet simplement de gagner du temps jusqu'au redémarrage sur le noyau approprié.
Il convient également de tenir compte des effets secondaires. La désactivation des espaces de noms utilisateur peut rendre inopérants les conteneurs sans privilèges root, Podman et Buildah sans privilèges root, certains environnements de compilation, les environnements sandbox et les outils qui dépendent de cette fonctionnalité. Sur un serveur d'hébergement classique avec une infrastructure web, une base de données, une messagerie et des tableaux de bord comme Plesk ou cPanel, cette solution est généralement acceptable. En revanche, sur un nœud de conteneur ou dans des environnements de développement avancés, son application doit être envisagée avec la plus grande prudence.
Debian et Ubuntu : différences de fonctionnement
Sous Debian et Ubuntu, le correctif est généralement appliqué en mettant à jour les paquets du noyau :
apt update
apt full-upgrade -y
reboot
Après le redémarrage :
uname -r
dpkg -l 'linux-image*' | grep '^ii'
Sur ces distributions, le paramètre suivant peut également être présent :
kernel.unprivileged_userns_clone
Pour atténuer temporairement le problème sous Debian/Ubuntu, il est donc courant de voir :
sysctl -w kernel.unprivileged_userns_clone=0
printf 'kernel.unprivileged_userns_clone = 0\n' > /etc/sysctl.d/99-disable-unpriv-userns.conf
sysctl --system
Ce paramètre ne doit pas être considéré comme acquis sur les systèmes AlmaLinux ou de type RHEL. Dans ces contextes, le paramètre le plus approprié à utiliser est user.max_user_namespaces.
Intervention prioritaire pour les administrateurs d'hébergement et de serveurs Linux.
Dans une infrastructure réelle, tous les systèmes n'ont pas la même priorité. Le classement pratique pourrait être le suivant.
Priorité maximale pour les hôtes exécutant des conteneurs, des environnements Kubernetes, des serveurs multilocataires, des machines avec des shells utilisateur, des systèmes CI/CD et des serveurs exécutant du code client ou de développeur qui n'est pas entièrement fiable.
Les serveurs web exposés à Internet sont prioritaires , même s'ils ne fournissent pas d'accès direct à Internet. Une vulnérabilité applicative dans WordPress, Magento, PrestaShop, Joomla ou un plugin peut permettre un accès local initial, et une telle vulnérabilité (CVE) au niveau du noyau peut transformer cet accès limité en une compromission totale.
Priorité habituelle mais nécessaire pour les serveurs isolés, sans utilisateurs locaux ni conteneurs. Dans ce cas également, le correctif doit être appliqué, mais la fenêtre de maintenance peut être planifiée avec moins d'urgence que dans un environnement mutualisé.
Pourquoi la mise à jour du noyau exige de la discipline
Les vulnérabilités locales du noyau sont parfois négligées car elles n'exposent pas directement un service réseau. C'est une erreur. Dans une chaîne d'attaque moderne, le plus difficile n'est pas toujours d'obtenir un accès initial : il s'agit souvent de le maintenir, de l'élever et de se déplacer latéralement. Une élévation de privilèges locale fiable est précisément ce qui permet à un attaquant de transformer un incident limité en un problème d'infrastructure.
Dans le cas de la CVE-2026-23111, le risque est accru par la publication de détails techniques et de reproductions indépendantes. Cela ne signifie pas que tous les systèmes sont automatiquement compromis, mais que le délai entre la divulgation publique et l'exploitation effective se réduit. Lorsqu'une faille du noyau devient compréhensible, reproductible et documentée, les attaquants ont l'avantage du temps.
conclusion
CVE-2026-23111 est une vulnérabilité techniquement élégante et dangereuse sur le plan opérationnel : un seul caractère incorrect dans le code de nf_tables Cela peut mener à une vulnérabilité de type « use-after-free » exploitable pour une élévation de privilèges locale jusqu'à l'administrateur. Bien qu'il ne s'agisse pas d'une vulnérabilité distante directe, elle est très pertinente dans tout environnement où un utilisateur non privilégié, un conteneur ou un processus compromis peut interagir avec le noyau via les espaces de noms utilisateur et les nftables.
La recommandation est claire : Mettez à jour le noyau depuis le dépôt officiel de votre distribution et redémarrez.En attendant le redémarrage, sur AlmaLinux et les distributions de type RHEL, il est possible d'atténuer temporairement ce problème en configurant user.max_user_namespaces = 0mais en évaluant l'impact sur les conteneurs sans racines et les bacs à sable.
Pour les responsables d'infrastructures d'hébergement, de serveurs Linux et d'environnements mutualisés, cette vulnérabilité (CVE) rappelle un principe fondamental : la sécurité ne se limite pas à la mise à jour des applications web. Le noyau, les espaces de noms, le pare-feu et les fonctionnalités apparemment « de bas niveau » font partie intégrante de la surface d'attaque. Un système à jour, redémarré avec le noyau approprié et configuré avec une surface d'attaque minimale demeure la meilleure façon de réduire les risques opérationnels.
