Sécurité 10 juillet 2026 à 09:30

Collaborer avec mon assistant IA :

GhostLock (CVE-2026-43499): faille Linux locale root et container escape à patcher

GhostLock, suivie sous CVE-2026-43499, est une faille locale du noyau Linux dans rtmutex/futex PI. Elle peut mener à une élévation de privilèges root et à une évasion de conteneur sur noyau vulnérable.

Illustration d'une veille sécurité CVE autour de GhostLock CVE-2026-43499 dans le noyau Linux

Dans le cadre de notre veille sécurité, nous signalons GhostLock, suivie sous l’identifiant CVE-2026-43499.

Le sujet est sérieux: GhostLock touche le noyau Linux, plus précisément le code rtmutex utilisé notamment dans certains chemins futex PI. Les sources publiques décrivent une vulnérabilité locale de type use-after-free pouvant mener à une élévation de privilèges root. Nebula Security indique aussi avoir transformé le bug en exploit de container escape dans un environnement de recherche.

Ce n’est pas une faille distante qui permettrait, seule, d’entrer sur un serveur exposé sur Internet. Mais dès qu’un attaquant peut exécuter du code localement, le risque change de nature: un accès limité peut devenir un contrôle complet de l’hôte.

Ce que l’on sait sur CVE-2026-43499

D’après le NVD, la vulnérabilité vient d’un mauvais usage de current dans remove_waiter() au lieu de la tâche réellement portée par waiter::task.

Dit plus simplement: dans un chemin classique, le thread courant est bien celui dont il faut nettoyer l’état. Dans le chemin de rollback proxy utilisé avec rt_mutex_start_proxy_lock() et futex_requeue(), ce n’est plus vrai. Le code nettoie alors le mauvais contexte.

Les conséquences décrites par kernel.org et reprises par le NVD sont importantes:

un retrait d’arbre rouge-noir peut se produire sans le bon verrou pi_lock;
l’état pi_blocked_on de la tâche attendue n’est pas correctement nettoyé;
un pointeur pendu reste présent et peut mener à un use-after-free;
la chaîne de priorité rt_mutex_adjust_prio_chain() peut travailler sur la mauvaise tâche.

Le CNA kernel.org attribue à CVE-2026-43499 un score CVSS 3.1 de 7.8 HIGH, avec le vecteur AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Le NVD classe aussi la faiblesse en CWE-416: Use After Free.

Pourquoi GhostLock doit être traité rapidement

Une élévation locale Linux ne doit pas être minimisée.

Sur une infrastructure moderne, du code local non totalement maîtrisé peut apparaître dans beaucoup de contextes:

conteneurs applicatifs;
noeuds Kubernetes;
runners CI/CD;
plateformes de build;
hébergements multi-utilisateurs;
bastions;
postes développeurs;
serveurs applicatifs après compromission initiale;
environnements qui exécutent des scripts, plugins ou traitements fournis par des tiers.

Dans ces cas, le risque n’est pas seulement “comment l’attaquant entre ?”. Le vrai sujet est: que peut-il devenir une fois entré ?

GhostLock est précisément le type de faille qui peut transformer un accès local limité en compromission de l’hôte. Pour les plateformes de conteneurs, c’est encore plus sensible: un conteneur repose sur le noyau de l’hôte. Si le noyau est vulnérable et que les conditions d’exploitation sont réunies, reconstruire l’image applicative ne corrige rien.

Versions impactées d’après le CPE du NVD

Le NVD liste les configurations CPE vulnérables suivantes pour cpe:2.3:o:linux:linux_kernel.

Produit	Versions impactées d'après le CPE NVD	Seuil corrigé indiqué par le CPE
Linux kernel	2.6.39 à avant 6.1.175	6.1.175
Linux kernel	6.2 à avant 6.6.140	6.6.140
Linux kernel	6.7 à avant 6.12.86	6.12.86
Linux kernel	6.13 à avant 6.18.27	6.18.27
Linux kernel	6.19 à avant 7.0.4	7.0.4

Ce tableau doit être lu avec prudence en exploitation.

Les distributions Linux backportent souvent des correctifs de sécurité dans des paquets dont le numéro de noyau reste proche de la branche maintenue. Un noyau Debian, Ubuntu, RHEL, Rocky, AlmaLinux, SUSE, Proxmox ou cloud provider peut donc être corrigé sans afficher exactement la version mainline attendue.

La bonne référence reste:

le noyau réellement chargé;
le bulletin de sécurité de votre distribution;
le changelog du paquet noyau;
la présence du correctif dans la branche stable utilisée;
la preuve post-redémarrage ou livepatch.

Hôtes à prioriser

La priorité dépend de la capacité d’un attaquant à exécuter du code localement.

À regarder en premier:

noeuds Kubernetes et hôtes Docker;
runners CI/CD et serveurs de build;
plateformes SaaS qui exécutent du code client ou des extensions;
bastions et machines partagées;
serveurs applicatifs exposés qui pourraient donner un shell après une faille applicative;
postes développeurs;
hôtes multi-utilisateurs;
environnements de test où des PoC ou binaires non maîtrisés sont exécutés;
serveurs sur lesquels des conteneurs disposent de privilèges larges.

Un serveur Linux isolé, sans utilisateur local non fiable et sans conteneurs, n’a pas le même niveau d’urgence qu’un worker Kubernetes multi-tenant. Mais il reste dans le périmètre si son noyau appartient aux plages vulnérables et si la distribution n’a pas backporté le correctif.

Vérifier sans exécuter le PoC

Le PoC GhostLock n’est pas un outil de recette production. Les sources publiques indiquent qu’il peut au minimum provoquer un crash ou un blocage système selon l’environnement. En production, il faut éviter les tests destructifs.

Commencez par relever le noyau réellement chargé:

uname -r

Sur Debian ou Ubuntu, vérifiez les paquets noyau installés:

dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'

Sur les distributions RPM:

rpm -qa | grep -E '^kernel|^kernel-core' | sort

Sur un parc conteneurisé, identifiez les hôtes qui portent réellement les workloads:

findmnt -T /var/lib/kubelet 2>/dev/null || findmnt -T /var/lib/docker 2>/dev/null || true

Ces commandes ne prouvent pas, seules, que l’hôte est vulnérable ou corrigé. Elles donnent la base à comparer aux bulletins de sécurité de votre distribution.

Mitigation temporaire: peu de marge, donc patch prioritaire

Openwall résume le point opérationnel de façon assez directe: il n’y a pas de module simple à bloquer ni de paramètre évident qui neutralise proprement GhostLock. La correction passe par le noyau corrigé.

En attendant une fenêtre de maintenance, les seules réductions de risque réalistes sont contextuelles:

réduire l’exécution de code non fiable sur les hôtes vulnérables;
déplacer les workloads les plus risqués vers des noeuds corrigés;
éviter de mélanger conteneurs non fiables et services critiques sur le même hôte;
restreindre les accès shell et les comptes locaux non nécessaires;
accélérer le patch des workers Kubernetes, runners CI et bastions;
surveiller les crashs, hangs et comportements noyau inhabituels.

Ces mesures ne remplacent pas le correctif. Elles réduisent seulement l’exposition pendant la préparation du redémarrage.

Patcher un noyau Linux: ne pas oublier le redémarrage

Sur une faille noyau, installer le paquet ne suffit pas toujours.

La séquence saine:

inventorier les hôtes Linux;
classer les hôtes à risque local élevé;
vérifier les bulletins distribution;
installer le noyau corrigé ou activer le livepatch validé;
redémarrer si nécessaire;
contrôler le noyau réellement chargé;
conserver les preuves d’intervention.

Après maintenance:

uname -a

Puis comparez la version chargée avec le bulletin de votre distribution. Si un livepatch est utilisé, il faut aussi prouver que le correctif est bien actif, pas seulement que l’agent est installé.

Notre lecture opérationnelle

GhostLock illustre une leçon récurrente sur les failles noyau Linux: le score CVSS ne suffit pas à décider seul de la priorité.

Le bon raisonnement croise plusieurs éléments:

la présence d’un noyau concerné;
l’existence d’un correctif dans votre branche;
la possibilité d’exécution locale par un attaquant;
la présence de conteneurs ou de workloads non fiables;
la criticité des hôtes;
la capacité à redémarrer sans casser la production.

Chez Forget About IT, ce type d’alerte entre directement dans le maintien en condition de sécurité: veille CVE, qualification du parc, priorisation, mitigation temporaire si elle existe, patch management, redémarrage contrôlé et vérification post-intervention.

La réponse doit être rapide, mais elle doit rester exploitable. Redémarrer tous les noeuds d’un cluster en même temps peut créer un incident. Ne jamais redémarrer après installation du noyau corrigé laisse l’ancien noyau vulnérable en production.

Conclusion

GhostLock (CVE-2026-43499) est une faille locale du noyau Linux à traiter sérieusement, surtout sur les hôtes qui exécutent des conteneurs, des jobs CI/CD, des workloads non fiables ou des sessions utilisateurs.

Le bon réflexe:

vérifier le noyau réellement chargé;
comparer avec les bulletins de votre distribution;
prioriser conteneurs, Kubernetes, CI/CD, bastions et hôtes partagés;
éviter les PoC en production;
installer le noyau corrigé;
redémarrer ou valider le livepatch;
conserver la preuve de correction.

Si vous avez besoin d’aide pour qualifier l’exposition ou organiser la remédiation sur vos serveurs Linux, nous pouvons vous accompagner dans le cadre de notre infogérance Linux.

Sources

FAQ: GhostLock et CVE-2026-43499

Qu’est-ce que GhostLock, ou CVE-2026-43499 ?

GhostLock est une vulnérabilité locale du noyau Linux, suivie sous CVE-2026-43499. Elle touche le code rtmutex et certains chemins futex PI. Le problème peut laisser un pointeur pendu et mener à un use-after-free exploitable pour obtenir des privilèges plus élevés.

GhostLock est-elle exploitable à distance ?

Non. Les sources publiques la décrivent comme une vulnérabilité locale. L’attaquant doit déjà pouvoir exécuter du code sur l’hôte, dans un conteneur ou dans un environnement local équivalent.

Quels noyaux Linux sont affectés d’après le CPE NVD ?

Le NVD liste comme affectés les noyaux Linux de 2.6.39 à avant 6.1.175, de 6.2 à avant 6.6.140, de 6.7 à avant 6.12.86, de 6.13 à avant 6.18.27, et de 6.19 à avant 7.0.4.

Existe-t-il une mitigation simple contre GhostLock ?

Les sources publiques ne donnent pas de mitigation simple équivalente au blocage d’un module. La réponse durable est l’installation d’un noyau corrigé, puis le redémarrage ou la validation d’un livepatch effectif.

Faut-il exécuter le PoC GhostLock en production ?

Non. Un PoC noyau peut provoquer un crash, un blocage ou une élévation de privilèges. En production, il faut privilégier les vérifications non destructives: noyau chargé, bulletins distribution, exposition des conteneurs et preuve de correction.