Un chercheur en sécurité a publié un exploit fonctionnel et extrêmement fiable pour une faille du noyau Linux qui permet à un utilisateur ordinaire, sans aucun privilège, de prendre le contrôle total d'une machine en tant que root - sans mot de passe, sans ingénierie sociale, uniquement par exécution de code local. Cette faille de type Local Privilege Escalation (LPE), répertoriée sous le nom CVE-2026-46242 et surnommée "Bad Epoll", touche les serveurs et postes Linux ainsi que les téléphones Android exécutant un noyau 6.4 ou plus récent. Un correctif existe déjà en amont, mais il n'est pas encore largement déployé.
Comment fonctionne le use-after-free de Bad Epoll
Le bug se situe dans epoll, le mécanisme que le noyau Linux utilise pour permettre à un seul programme de surveiller simultanément des milliers de fichiers ouverts ou de connexions réseau - un mécanisme dont dépendent pratiquement tous les serveurs web, bases de données et démons VPN. Le chercheur Jaeyoung Chung, du Computer Security Lab de l'université nationale de Séoul, a découvert que lorsque deux routines internes de nettoyage d'epoll, situées dans la fonction ep_remove(), s'exécutent en même temps, l'une peut libérer une zone de mémoire du noyau pendant que l'autre continue d'y écrire. Cette fenêtre de use-after-free ne dure qu'environ six instructions CPU, mais le proof-of-concept de Chung, désormais public sur GitHub, exploite cette mémoire corrompue pour construire une chaîne de programmation orientée retour (ROP) qui détourne le flux d'exécution du noyau et accorde les droits root à l'attaquant.
Qui est concerné
- Serveurs et postes Linux : toute distribution exécutant un noyau mainline à partir de la version 6.4 est vulnérable.
- Appareils Android : fonctionnement confirmé sur un Google Pixel 10 (noyau 6.6) ; les appareils plus anciens encore sur la branche LTS 6.1 ne sont pas affectés.
- Le navigateur comme point d'entrée : l'exploit ne nécessitant qu'une exécution de code locale, des chercheurs notent qu'il pourrait en théorie être lancé depuis un processus sandboxé comme un moteur de rendu Chrome, transformant un simple bug de navigateur en prise de contrôle complète de l'appareil.
La première tentative de correction des mainteneurs du noyau, publiée après le correctif d'une faille antérieure liée (CVE-2026-43074), n'a pas totalement comblé la brèche - il a fallu environ deux mois supplémentaires avant qu'un correctif adéquat n'atteigne le noyau mainline. Ce processus de correction lent, en deux temps, explique précisément pourquoi tant de systèmes restent exposés : les distributions et les fabricants Android accusent souvent plusieurs cycles de retard sur le mainline, et les serveurs autogérés encore davantage.
Comment vérifier si vous êtes concerné
Exécutez la commande uname -r dans un terminal pour connaître la version de votre noyau. Si elle indique 6.4 ou plus et que votre distribution ou votre appareil n'a reçu aucune mise à jour de sécurité depuis début juillet 2026, considérez le système comme vulnérable et appliquez dès que possible le dernier correctif du noyau ou du fabricant.
Pourquoi cela dépasse le cadre des ordinateurs personnels
Bad Epoll n'a pas besoin de connexion réseau pour fonctionner - seulement d'une exécution de code locale, ce qui peut sembler rassurant. Mais le "local" recouvre aujourd'hui un vaste territoire : serveurs d'hébergement mutualisé, runners CI/CD, instances VPS dans le cloud, appareils réseau auto-hébergés, et toute machine Linux qui exécute un jour du code non fiable - qu'il s'agisse d'un script téléchargé, d'une évasion de conteneur ou d'un onglet de navigateur compromis. Dès qu'un attaquant obtient le moindre point d'appui, aussi limité soit-il, Bad Epoll le transforme en contrôle administratif complet.
Une tendance plus large
Bad Epoll rappelle à quel point l'infrastructure réseau moderne - y compris les machines Linux qui font tourner des passerelles VPN, des proxys auto-hébergés et des routeurs domestiques - dépend d'un sous-système du noyau dont la plupart des utilisateurs n'ont jamais entendu parler. Une seule machine non corrigée sur un réseau partagé, ou un fournisseur VPN lent à déployer les mises à jour du noyau sur son parc de serveurs, peut transformer un bug "purement local" en une exposition bien plus large pour tous ceux dont le trafic y transite. Cette affaire s'inscrit dans une tendance récurrente cette année : du vol d'identifiants FortiGate à Citrix Bleed, le maillon le plus faible de l'infrastructure de la vie privée s'avère systématiquement être du code noyau ou firmware non corrigé et peu spectaculaire, plutôt que le chiffrement lui-même.
