# GhostLock (CVE-2026-43499): faille Linux locale root et container escape à patcher > GhostLock CVE-2026-43499: point opérationnel sur cette faille Linux locale rtmutex/futex PI, versions impactées d'après le NVD et mesures à prendre. - URL canonique : [https://forgetaboutit.fr/blog/ghostlock-cve-2026-43499-linux-root-container-escape/](https://forgetaboutit.fr/blog/ghostlock-cve-2026-43499-linux-root-container-escape/) - Publication : 2026-07-10T07:30:00.000Z - Catégorie : Sécurité - Sujets : GhostLock, CVE-2026-43499, CVE, Linux, Kernel, Élévation de privilèges, Conteneurs, Patch management, Cybersécurité 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é: ```bash uname -r ``` Sur Debian ou Ubuntu, vérifiez les paquets noyau installés: ```bash dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}' ``` Sur les distributions RPM: ```bash rpm -qa | grep -E '^kernel|^kernel-core' | sort ``` Sur un parc conteneurisé, identifiez les hôtes qui portent réellement les workloads: ```bash 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: 1. inventorier les hôtes Linux; 2. classer les hôtes à risque local élevé; 3. vérifier les bulletins distribution; 4. installer le noyau corrigé ou activer le livepatch validé; 5. redémarrer si nécessaire; 6. contrôler le noyau réellement chargé; 7. conserver les preuves d'intervention. Après maintenance: ```bash 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](/infogerance/). - [Découvrir notre infogérance Linux](/infogerance/) - [Lire notre article sur le suivi quotidien des CVE](/blog/suivi-cve-pourquoi-quotidien/) - [Nous contacter](/contact/) - [Prendre rendez-vous](https://koalendar.com/e/faboutit) ## Sources - NVD - CVE-2026-43499 - Nebula Security - IonStack part II: GhostLock - oss-security - Linux: GhostLock / CVE-2026-43499 - Linux stable - correctif 3bfdc63936dd ## 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.