Bad Epoll : CVE-2026-46242 donne root sur Linux

Une nouvelle vulnérabilité du noyau Linux, suivie sous l’identifiant CVE-2026-46242 et surnommée “Bad Epoll” dans la couverture médiatique, est présentée comme une élévation de privilèges locale permettant à un utilisateur non privilégié d’obtenir les droits root. La faille concerne le noyau Linux et son impact est également signalé sur Android, qui repose lui aussi sur ce noyau. La source de référence mentionnée ici est la couverture publiée par The Hacker News, qui relaie l’existence du problème et l’importance des correctifs diffusés par l’écosystème Linux et les constructeurs Android.

À ce stade, le point essentiel pour les équipes d’exploitation, d’administration système, de sécurité et de développement n’est pas seulement le fait qu’il s’agisse d’une faille “locale”, mais le contexte dans lequel ce type de vulnérabilité devient immédiatement critique en production. Sur un serveur web, une plateforme mutualisée, un nœud Kubernetes, un environnement CI/CD, un VPS hébergeant plusieurs services, ou encore un smartphone Android d’entreprise, une élévation de privilèges noyau permet typiquement de passer d’un compte restreint à une compromission complète de la machine. Cela inclut l’accès à l’ensemble des données locales, la neutralisation de mécanismes de sécurité, l’installation de persistance et, dans certains cas, des mouvements latéraux vers d’autres systèmes.

Le score CVSS exact doit être vérifié dans l’advisory officielle de l’éditeur ou du mainteneur concerné. La couverture médiatique met surtout en avant la gravité opérationnelle du défaut et la disponibilité de correctifs via les distributions Linux et les OEM Android. En l’absence, dans la source fournie, d’un bulletin éditeur détaillant précisément toutes les branches corrigées et tous les numéros de versions, il faut s’en tenir à une recommandation factuelle : appliquer sans attendre les mises à jour noyau publiées par votre distribution ou votre fournisseur Android, puis redémarrer les systèmes concernés.

Pour les environnements web et serveurs, cette vulnérabilité doit être priorisée même si elle n’est pas exploitable à distance de manière autonome. En pratique, une faille locale noyau devient un multiplicateur d’impact dès qu’un attaquant obtient un pied sur la machine via une application web compromise, un compte SSH exposé, une tâche planifiée détournée, un conteneur mal isolé ou une chaîne de post-exploitation après vol d’identifiants. C’est précisément ce qui rend ce type de bug dangereux dans les infrastructures modernes.

Versions affectées

La couverture initiale indique que la vulnérabilité touche le noyau Linux et qu’un impact est également observé sur Android. En revanche, la source secondaire fournie ne détaille pas, à elle seule, la liste exhaustive des versions vulnérables et corrigées pour chaque branche du noyau, chaque distribution ou chaque constructeur mobile. Dans ce contexte, il serait imprudent d’inventer une matrice de versions.

Les éléments factuels que l’on peut retenir sont les suivants :

• Produit affecté : noyau Linux
• Écosystèmes impactés : distributions Linux serveur et poste de travail, ainsi que Android via les noyaux intégrés par les OEM
• Type de faille : élévation de privilèges locale depuis un compte non privilégié vers root
• Correctif : une version corrigée a été publiée par les mainteneurs et relayée ensuite par les distributions et fournisseurs concernés

En pratique, pour identifier précisément les versions affectées dans votre parc, il faut s’appuyer sur les advisories officielles de votre fournisseur :

• bulletins de sécurité de la distribution Linux utilisée
• pages de suivi du paquet linux-image, kernel ou équivalent
• annonces de sécurité Android et bulletins OEM
• éventuellement avis du CERT-FR si une note de veille ou de recommandation est publiée

Quelques points de contrôle utiles côté Linux :

• sur Debian et Ubuntu, vérifier le noyau installé avec uname -r puis comparer avec les versions corrigées proposées dans les dépôts de sécurité ;
• sur RHEL, AlmaLinux, Rocky Linux, Oracle Linux ou Fedora, vérifier les annonces de mise à jour du paquet kernel ;
• sur SUSE et openSUSE, consulter les bulletins de maintenance et de sécurité associés au noyau ;
• sur les environnements managés chez OVHcloud, Scaleway, o2switch ou d’autres hébergeurs français, vérifier si l’infrastructure fournie inclut un noyau géré par le client ou par le prestataire.

Pour Android, la réalité opérationnelle est plus fragmentée. Le correctif peut être disponible dans un bulletin Android, mais son déploiement effectif dépend ensuite du constructeur, de l’opérateur et du cycle de mise à jour de l’appareil. Il faut donc distinguer :

• la disponibilité du correctif dans l’écosystème Android amont ;
• sa disponibilité sur le terminal réellement utilisé ;
• l’installation effective de la mise à jour par l’utilisateur ou l’administrateur MDM.

En l’absence d’une liste consolidée et officielle dans la source fournie, la règle de prudence est simple : considérer comme potentiellement vulnérable tout système Linux ou Android non encore mis à jour avec le correctif publié par son fournisseur.

Vecteur d'attaque

CVE-2026-46242 est décrite comme une faille locale d’élévation de privilèges. Cela signifie qu’un attaquant doit déjà disposer d’une capacité d’exécution sur la machine ciblée, même avec des droits très limités, pour tenter l’exploitation. Dit autrement, cette vulnérabilité n’est pas, d’après les éléments disponibles ici, une faille de type RCE réseau autonome. Pourtant, dans un contexte serveur, cela ne réduit pas nécessairement sa sévérité réelle.

Le terme “Bad Epoll” suggère un problème lié au sous-système epoll, composant central de Linux pour la gestion efficace des événements d’entrées/sorties. epoll est largement utilisé par les serveurs web, reverse proxies, runtimes applicatifs, intermédiaires réseau et de nombreuses briques d’infrastructure. Lorsqu’une erreur de gestion mémoire, de synchronisation ou de validation d’état touche une primitive noyau de ce niveau, le risque est qu’un utilisateur local puisse manipuler le comportement du noyau pour sortir de son périmètre de privilèges.

Sans reproduire de détails d’exploitation non confirmés par l’advisory officielle, le scénario générique est le suivant :

• un utilisateur non privilégié exécute un programme local ;
• ce programme interagit avec des interfaces noyau liées à epoll ;
• une condition défaillante dans le noyau permet de corrompre un état interne ou de contourner une vérification ;
• l’attaquant obtient finalement une exécution avec les privilèges root ou un contrôle équivalent sur le système.

Dans un environnement web, les chemins d’accès à cette “position locale” sont nombreux :

Post-exploitation après compromission applicative

Une application web vulnérable à une injection de commande, à un upload de fichier exécutable, à une désérialisation ou à une RCE dans un framework peut offrir à l’attaquant un shell sous l’identité de service, par exemple www-data, nginx, apache ou un utilisateur applicatif dédié. Si ce compte peut ensuite exploiter une faille noyau locale, la compromission passe d’un conteneur ou d’un service isolé à la prise de contrôle complète de l’hôte.

Multi-tenant et mutualisation

Dans les environnements hébergeant plusieurs clients ou plusieurs équipes sur une même machine, la frontière entre utilisateurs locaux est une hypothèse de sécurité forte. Une faille locale noyau casse précisément cette hypothèse. Sur une plateforme mutualisée, un client malveillant ou compromis peut potentiellement viser l’hôte ou les autres charges de travail. C’est particulièrement sensible pour :

• les hébergements mutualisés ;
• les bastions partagés ;
• les serveurs de build ;
• les runners CI/CD ;
• les nœuds de calcul et environnements universitaires ;
• les PaaS et certaines offres VPS mal segmentées.

Conteneurs et évasion vers l’hôte

Un conteneur n’est pas une machine virtuelle complète ; il partage le noyau de l’hôte. C’est pourquoi une vulnérabilité du noyau Linux reste critique même si les applications sont “conteneurisées”. Si un attaquant obtient une exécution dans un conteneur avec un utilisateur peu privilégié, une élévation de privilèges noyau peut ouvrir la voie à une sortie de confinement, selon la configuration du conteneur, les capacités accordées, les mécanismes seccomp, AppArmor, SELinux et l’état du noyau hôte.

Le risque est encore plus marqué si l’on observe l’une des mauvaises pratiques suivantes :

• conteneurs lancés en mode --privileged ;
• montage du socket Docker dans un conteneur ;
• ajout de capacités Linux non nécessaires ;
• désactivation de profils de sécurité ;
• cohabitation de workloads de niveaux de confiance différents sur le même nœud.

Poste de travail et Android

Sur un poste Linux ou un terminal Android, l’exploitation locale peut servir à sortir d’un bac à sable, contourner des mécanismes de séparation entre applications ou obtenir un contrôle administrateur complet après l’exécution initiale d’un code malveillant. Là encore, la faille n’est pas “moins grave” parce qu’elle est locale : elle devient un maillon de chaîne d’attaque particulièrement puissant.

Impact

L’impact signalé pour CVE-2026-46242 est l’obtention des droits root. Sur Linux, cela signifie en pratique une compromission quasi totale du système concerné. Les conséquences dépendent du rôle de la machine, mais elles incluent généralement les capacités suivantes :

• lecture et modification de tous les fichiers locaux ;
• accès aux secrets applicatifs stockés sur disque ;
• lecture potentielle de clés privées, certificats, tokens et mots de passe ;
• désactivation ou altération d’agents de sécurité ;
• installation de portes dérobées et mécanismes de persistance ;
• modification des règles réseau locales ;
• interception de trafic ou de communications inter-processus ;
• pivot vers d’autres systèmes accessibles depuis la machine compromise.

Pour un serveur web, quelques scénarios concrets illustrent pourquoi une faille locale noyau doit remonter très haut dans la file de patch :

Serveur LAMP/LEMP compromis via une application web

Une RCE dans une application PHP, Node.js, Python ou Java permet d’obtenir un shell sous un compte restreint. Sans faille locale, l’attaquant reste parfois cantonné au périmètre du service. Avec une élévation de privilèges noyau, il peut :

• accéder aux bases de données locales ou aux fichiers de configuration contenant les identifiants ;
• modifier le serveur web ou l’OS pour maintenir un accès ;
• voler des secrets de déploiement ;
• compromettre d’autres applications hébergées sur la même machine.

Nœud Kubernetes ou Docker

Un conteneur compromis sur un nœud vulnérable peut devenir le point de départ d’une compromission de l’hôte. Une fois root sur l’hôte, l’attaquant peut potentiellement :

• lire les volumes et secrets montés ;
• accéder aux autres conteneurs du nœud ;
• manipuler le runtime de conteneur ;
• utiliser la machine comme tremplin vers le cluster.

Environnement mutualisé ou bastion partagé

Un simple compte utilisateur, même sans privilèges administrateur, peut suffire à lancer l’exploitation. Dans un environnement partagé, cela remet en cause la séparation entre clients ou entre équipes. Pour un hébergeur ou un prestataire, le risque n’est alors plus seulement individuel mais systémique.

En termes de priorisation, une élévation de privilèges locale noyau doit souvent être traitée comme critique en contexte dès lors qu’au moins une des conditions suivantes est remplie :

• présence d’utilisateurs locaux multiples ;
• hébergement de charges de travail non totalement maîtrisées ;
• exposition Internet d’applications pouvant fournir un point d’entrée initial ;
• utilisation de conteneurs ;
• machine manipulant des données sensibles ou des secrets d’infrastructure.

Comment patcher

La remédiation prioritaire consiste à installer la version corrigée du noyau publiée par votre distribution Linux ou, côté Android, à déployer la mise à jour de sécurité fournie par l’OEM. Comme le noyau est concerné, un redémarrage est généralement nécessaire pour que le correctif soit réellement actif.

La première étape consiste à identifier le noyau actuellement chargé :

uname -r

Sur les distributions Linux courantes, les commandes de mise à jour sont les suivantes.

Debian / Ubuntu

Mettre à jour l’index des paquets puis installer les mises à jour de sécurité disponibles, y compris le noyau :

sudo apt update
sudo apt full-upgrade -y

Selon la politique de votre distribution, il peut aussi être utile de vérifier les paquets noyau installés :

dpkg -l | grep linux-image

Après installation du noyau corrigé publié par l’éditeur, redémarrer :

sudo reboot

RHEL / AlmaLinux / Rocky Linux / Oracle Linux / CentOS Stream / Fedora

Sur les distributions utilisant dnf :

sudo dnf upgrade --refresh -y

Sur certains environnements plus anciens utilisant encore yum :

sudo yum update -y

Vérifier ensuite les versions du paquet kernel installées, puis redémarrer pour charger la version corrigée :

rpm -qa | grep '^kernel'
sudo reboot

SUSE / openSUSE

sudo zypper refresh
sudo zypper update -y

Puis redémarrage :

sudo reboot

Vérification post-correctif

Après redémarrage, confirmer que le noyau actif correspond bien à la version corrigée publiée par votre fournisseur :

uname -r

Sur les environnements à haute disponibilité, prévoir une stratégie de déploiement adaptée :

• drain des nœuds Kubernetes avant redémarrage ;
• bascule sur nœud secondaire pour les services stateful ;
• fenêtre de maintenance coordonnée pour les hyperviseurs et hôtes mutualisés ;
• vérification de compatibilité avec les modules noyau tiers.

Android

Pour Android, il n’existe pas de commande universelle comparable à apt ou dnf, car le déploiement dépend du constructeur. L’action correcte est de :

• vérifier la disponibilité d’une mise à jour système dans les réglages de l’appareil ;
• contrôler le niveau de correctif de sécurité Android ;
• appliquer la mise à jour OEM dès qu’elle est proposée ;
• forcer le déploiement via MDM/EMM si l’appareil est administré en entreprise.

Pour les flottes mobiles professionnelles, il est important de distinguer les appareils encore supportés de ceux qui ne reçoivent plus de correctifs. Un terminal Android non maintenu reste exposé même si le correctif existe dans l’écosystème amont.

Détection

Comme il s’agit d’une élévation de privilèges locale dans le noyau, la détection n’est pas toujours triviale. Beaucoup d’exploitations locales laissent peu de traces applicatives évidentes, surtout si l’attaquant nettoie après coup. Il faut donc combiner plusieurs niveaux d’observation : inventaire des versions, télémétrie système, journaux de sécurité, événements de processus et signaux de compromission post-exploitation.

1. Inventorier les systèmes potentiellement vulnérables

Le premier indicateur de risque reste l’identification des hôtes exécutant un noyau non corrigé. Sur Linux :

uname -r

Dans un parc, cette vérification doit être industrialisée via vos outils habituels : gestion de configuration, EDR, CMDB, inventaire cloud, scanner de vulnérabilités ou simple collecte via SSH automatisé.

Points d’attention :

• la présence du paquet corrigé ne suffit pas si la machine n’a pas redémarré ;
• dans les conteneurs, uname -r reflète le noyau de l’hôte ;
• sur les environnements virtualisés, le noyau vulnérable est celui de la VM, pas celui de l’hyperviseur, sauf cas particuliers.

2. Rechercher des élévations de privilèges anormales

Une exploitation réussie peut se traduire par des processus inattendus tournant en root, l’apparition de nouveaux comptes, des modifications de fichiers système ou des changements de configuration. Quelques axes de recherche :

• création ou modification de comptes dans /etc/passwd, /etc/shadow, /etc/sudoers ;
• ajout de clés SSH dans /root/.ssh/authorized_keys ou dans les comptes de service ;
• apparition de binaires setuid inhabituels ;
• services persistants ajoutés dans systemd, cron ou scripts d’initialisation ;
• chargement de modules noyau non attendus ;
• désactivation de journaux ou d’agents de sécurité.

Exemples de vérifications utiles :

find / -xdev -perm -4000 -type f 2>/dev/null
systemctl list-unit-files --state=enabled
crontab -l
sudo ls -la /etc/cron.d /etc/cron.daily /var/spool/cron

3. Examiner les journaux système

Selon la nature exacte du bug et la manière dont il est exploité, des traces peuvent apparaître dans journalctl, syslog, les logs d’audit ou les traces EDR. Il faut notamment surveiller :

• des crashs ou anomalies noyau inhabituels ;
• des séquences de processus courtes lancées par un compte de service puis suivies d’actions root ;
• des événements de type exécution locale depuis des répertoires temporaires ;
• des comportements d’exploitation après compromission web.

Exemples de commandes :

journalctl -k
journalctl -p err..alert
ausearch -m USER_START,USER_END,EXECVE --start recent

Si auditd est activé, il peut aider à reconstituer une chaîne d’exécution. Sinon, l’absence de télémétrie détaillée doit être considérée comme un angle mort à corriger.

4. Corréler avec des signaux de compromission applicative

Parce qu’une faille locale noyau intervient souvent après une compromission initiale, il faut corréler la recherche avec les logs web, les événements d’authentification et les alertes EDR. Quelques IoC contextuels, non spécifiques à un exploit particulier mais pertinents en investigation :

• exécution de commandes système par le compte du serveur web ;
• fichiers déposés dans /tmp, /dev/shm ou des répertoires d’upload ;
• processus enfants inattendus lancés par php-fpm, apache2, nginx, node, python ou java ;
• connexion sortante inhabituelle depuis un serveur web ;
• modification rapide de permissions sur des fichiers système ;
• usage anormal de compilateurs ou d’outils comme gcc, clang, make sur des serveurs de production où ils ne devraient pas être présents.

Exemples de recherche :

ps auxf
ss -plant
find /tmp /dev/shm -type f -mtime -2 -ls

5. Android : surveillance et gouvernance

Sur Android, la détection est plus dépendante des outils MDM/EMM, des solutions de défense mobile et du niveau de journalisation disponible. Les points clés sont :

• inventaire du niveau de correctif de sécurité ;
• identification des appareils hors support ;
• corrélation avec l’installation d’applications non approuvées ;
• surveillance des indicateurs de compromission remontés par les outils de gestion de flotte.

En cas de suspicion d’exploitation réussie, la réponse doit être traitée comme une compromission complète de l’équipement.

Mitigation

Le correctif noyau reste la seule réponse pérenne. Lorsqu’un patch ne peut pas être appliqué immédiatement, les mesures de mitigation visent surtout à réduire les opportunités d’exploitation et à limiter l’impact d’un accès local initial. Elles ne remplacent pas la mise à jour.

Réduire l’exposition locale

• désactiver ou suspendre les accès shell non indispensables ;
• restreindre les comptes de service interactifs ;
• supprimer les utilisateurs obsolètes ;
• réduire les accès SSH aux seules adresses d’administration autorisées.

Exemple de contrôle des comptes shell :

getent passwd | grep -E '/bin/(bash|sh|zsh)$'

Durcir les charges conteneurisées

• éviter --privileged ;
• retirer les capacités Linux non nécessaires ;
• appliquer des profils seccomp ;
• activer AppArmor ou SELinux selon la distribution ;
• séparer les workloads à risque sur des nœuds dédiés.

Ces mesures ne corrigent pas le noyau, mais elles peuvent compliquer une chaîne d’exploitation ou réduire la surface accessible depuis un conteneur compromis.

Limiter les outils utiles à un attaquant local

Sur les serveurs de production, il est souvent pertinent de retirer les compilateurs et outils de build lorsqu’ils ne sont pas nécessaires. Beaucoup d’exploits publics de failles locales sont fournis sous forme de code à compiler localement. L’absence de chaîne de compilation n’empêche pas toutes les attaques, mais elle peut ralentir un adversaire opportuniste.

Renforcer la surveillance

• activer ou renforcer auditd ;
• surveiller les répertoires temporaires ;
• détecter les exécutions depuis /tmp et /dev/shm ;
• corréler les actions des comptes de service avec des événements de privilège.

Segmenter et isoler

Sur les plateformes mutualisées ou multi-tenant, si la mise à jour ne peut pas être immédiate, il faut envisager des mesures temporaires plus fortes :

• réduction du nombre de tenants par hôte ;
• déplacement des charges les plus sensibles ;
• désactivation temporaire de certains accès clients ;
• priorisation des hôtes exposés à Internet ou recevant du code non maîtrisé.

Pour Android en entreprise, une mitigation réaliste consiste à bloquer l’accès aux ressources sensibles depuis les terminaux qui n’ont pas encore reçu le correctif, via les politiques MDM, l’accès conditionnel ou la segmentation réseau.

Pourquoi une faille locale noyau reste critique en production

Le point le plus important de cette alerte est peut-être celui-ci : une faille locale dans le noyau n’est pas un problème “secondaire” réservé aux postes de travail. Dans les environnements serveurs modernes, elle est souvent l’élément qui transforme un incident limité en compromission majeure.

Trois réalités opérationnelles l’expliquent :

• les intrusions commencent rarement directement par root : l’attaquant obtient d’abord un accès partiel, puis cherche à l’étendre ;
• le noyau est la frontière ultime : si elle tombe, les mécanismes de séparation applicative perdent une grande partie de leur valeur ;
• les infrastructures sont densifiées : conteneurs, mutualisation, CI/CD, PaaS et nœuds partagés augmentent l’impact d’une élévation locale.

C’est pour cela que les administrateurs Linux doivent généralement prioriser ce type de faille sur :

• les serveurs exposés à Internet ;
• les hôtes de conteneurs ;
• les environnements mutualisés ;
• les bastions ;
• les systèmes hébergeant des secrets d’infrastructure ;
• les postes d’administration ;
• les terminaux Android d’entreprise encore supportés.

La source médiatique de départ est The Hacker News, qui relaie l’existence de CVE-2026-46242 et son impact sur Linux et Android. Pour l’action opérationnelle, la bonne pratique reste de s’appuyer ensuite sur les bulletins officiels des distributions Linux et des OEM Android, car ce sont eux qui publient les versions corrigées, le calendrier de disponibilité et les modalités exactes de déploiement.

Si votre organisation exploite des serveurs Linux pour des applications web, des nœuds de conteneurs ou des environnements mutualisés, la priorité immédiate est de vérifier les noyaux actifs, d’appliquer les mises à jour de sécurité disponibles et de redémarrer les hôtes concernés. En parallèle, un contrôle des traces de post-exploitation et des mécanismes de persistance est recommandé sur les machines les plus exposées. Pour renforcer durablement la résilience, un travail de fond sur le durcissement système, la réduction des privilèges et l’isolation des workloads reste indispensable ; des mesures complémentaires de hardening sont à retrouver dans la catégorie /categorie/pratiques.