> ## Documentation Index > Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt > Use this file to discover all available pages before exploring further. # GhostLock (CVE-2026-43499) : quinze ans de noyau, root en cinq secondes > Un use-after-free dans l'héritage de priorité des futex donne root à n'importe quel utilisateur local et sort des conteneurs. Aucun contournement possible. *Publié le 8 août 2026* **CVE-2026-43499, surnommée « GhostLock ».** Un exploit public passe d'un compte non privilégié à root en environ cinq secondes. Aucune atténuation à chaud n'existe : il faut un noyau corrigé, puis un redémarrage. ## La faille en deux phrases Il s'agit d'un use-after-free dans le sous-système de verrouillage du noyau, sur le chemin d'héritage de priorité des futex — la mécanique derrière les mutex `PTHREAD_PRIO_INHERIT` de la glibc. Une étape de nettoyage dans `remove_waiter()` efface la comptabilité du mauvais thread et laisse un thread vivant pointer sur de la mémoire déjà libérée. L'objet libéré se trouve sur la pile du noyau, et non sur le tas où vit l'immense majorité des bugs de cette famille. C'est ce détail qui rend l'exploitation aussi fiable. Le seul prérequis est `CONFIG_FUTEX_PI=y`, activé par défaut dans toutes les distributions majeures. Le code a été introduit dans Linux 2.6.39-rc1 en mai 2011 et est resté vulnérable jusqu'à la v7.1-rc1 : autant dire tous les noyaux de production des quinze dernières années. ## Pourquoi celle-ci sort du lot Les élévations de privilèges locales sont fréquentes et finissent d'ordinaire en bas de la pile des priorités. Deux propriétés changent la donne ici. **L'exploit est public et il fonctionne.** La chaîne complète publiée atteint root en cinq secondes environ, avec une fiabilité de l'ordre de 97 %. Ce n'est pas une preuve de concept qui exige un noyau précis et un vent favorable : c'est un outil qui marche. **Il sort des conteneurs.** Un processus non privilégié dans un conteneur obtient root sur l'hôte. Si vous faites tourner des charges tierces ou non auditées sur un nœud partagé, l'isolation sur laquelle vous comptez n'est pas là. ## Mesurer votre exposition La question n'est pas le score CVSS — il vaut 7,8, et ce chiffre vous apprend peu de chose ici. La question est : **qui peut exécuter du code sur votre machine ?** | Profil | Exposition | Action | | -------------------------------------------------------------------------------- | ---------------------- | ------------------------------------------------------------ | | VPS mono-locataire, votre code seul, aucun compte shell tiers | Modérée | Corriger lors de la prochaine fenêtre de maintenance | | VPS avec plusieurs comptes shell, des clients, ou un runner CI non audité | **Critique** | Corriger et redémarrer maintenant | | Nœud Docker ou Kubernetes exécutant des images tierces ou des charges dynamiques | **Critique** | Corriger tous les nœuds — l'isolation conteneur ne tient pas | | Hébergement mutualisé où vous ne gérez pas le noyau | Traité par l'hébergeur | Rien à faire de votre côté | Le schéma mérite d'être noté : la faille exige un point d'appui local. Elle n'est pas exploitable à distance en elle-même. Mais elle transforme n'importe quel appui modeste — une application web compromise, un compte peu privilégié fuité, une dépendance hostile dans un build — en contrôle total de la machine. ## Il n'y a pas de contournement C'est le point sur lequel beaucoup se trompent. Le bulletin de Red Hat le dit sans détour : aucun paramètre noyau à chaud, aucun module à désactiver ne corrige la faille. `CONFIG_FUTEX_PI` est compilé dans les noyaux standards et ne se désactive pas à l'exécution. Contrairement à une faille cantonnée à un module chargeable, vous ne pouvez pas gagner une semaine avec une liste noire `modprobe`. Vous corrigez et vous redémarrez, ou vous restez vulnérable. ## Appliquer le correctif ### Debian, Ubuntu et dérivées ```bash theme={null} # Récupérer les mises à jour de sécurité et mettre le noyau à niveau sudo apt update sudo apt full-upgrade # Le nouveau noyau n'est actif qu'après redémarrage sudo reboot ``` La version de paquet exacte se vérifie sur le tracker de votre distribution : [Ubuntu](https://ubuntu.com/security/CVE-2026-43499) et [Debian](https://security-tracker.debian.org/tracker/CVE-2026-43499). ### AlmaLinux, Rocky Linux et RHEL ```bash theme={null} sudo dnf clean metadata && sudo dnf upgrade sudo reboot ``` Versions de noyau corrigées sur AlmaLinux, ou toute version ultérieure : | Version | Noyau corrigé | | ------------ | -------------------------------- | | AlmaLinux 8 | `kernel-4.18.0-553.141.2.el8_10` | | AlmaLinux 9 | `kernel-5.14.0-687.24.1.el9_8` | | AlmaLinux 10 | `kernel-6.12.0-211.32.1.el10_2` | Le bulletin de Red Hat couvre RHEL 6 à 10, ainsi qu'OpenShift, OpenStack Platform, RHEL CoreOS et tous les produits bâtis sur le noyau RHEL. ### Vérifier le noyau réellement actif Installer le paquet n'est pas l'exécuter. Contrôlez après le redémarrage : ```bash theme={null} # Doit afficher la version corrigée, pas celle démarrée ce matin uname -r # Depuis combien de temps la machine tourne — une grande valeur après « correction » est le signal uptime -p ``` Sur un cluster Kubernetes, un nœud n'est corrigé qu'une fois redémarré. Drain, reboot, uncordon, un nœud à la fois : un paquet à jour sur un nœud non redémarré exécute toujours le noyau vulnérable. ## Chronologie La gestion a été propre, et cela mérite d'être souligné : la faille a été signalée le 18 avril par Nebula Security, corrigée en amont deux jours plus tard dans le commit `3bfdc63936dd`, rétroportée le 4 mai, et divulguée publiquement seulement le 7 juillet. Les distributions avaient leurs correctifs prêts avant la publication des détails. L'exploit a suivi dans la journée qui a suivi la divulgation. Si vos serveurs n'ont pas redémarré depuis début juillet, considérez que la fenêtre est restée ouverte depuis. ## En cas de suspicion de compromission Une élévation locale réussie laisse peu de traces, et un attaquant root peut effacer celles qui existent. N'essayez pas de nettoyer la machine sur place. La voie fiable est la reconstruction depuis un état sain : déployez une instance neuve, restaurez vos données depuis une sauvegarde antérieure au soupçon, et faites tourner tous les secrets que la machine détenait — clés SSH, jetons d'API, mots de passe de bases. Vos [snapshots](https://help.onetsolutions.net/fr/vps/snapshot) et [sauvegardes](https://help.onetsolutions.net/fr/vps/backup) servent précisément à cela. Le redémarrage après mise à jour du noyau est l'étape la plus souvent sautée en administration serveur. Au-delà de quelques machines, un inventaire des valeurs de `uname -r` vaut mieux que n'importe quel scanner. Besoin d'un avis sur l'état de votre parc ? [Notre équipe est disponible](https://help.onetsolutions.net/fr/console/support) depuis votre espace client.