Bad Epoll: CVE-2026-46242 gives root on Linux

A new Linux kernel vulnerability, tracked as CVE-2026-46242 and nicknamed “Bad Epoll” in media coverage, is presented as a local privilege escalation allowing an unprivileged user to obtain root privileges. The flaw affects the Linux kernel, and its impact is also reported on Android, which also relies on this kernel. The reference source mentioned here is the coverage published by The Hacker News, which relays the existence of the issue and the importance of the fixes released by the Linux ecosystem and Android manufacturers.

At this stage, the key point for operations, system administration, security, and development teams is not only that this is a “local” flaw, but the context in which this type of vulnerability immediately becomes critical in production. On a web server, a shared hosting platform, a Kubernetes node, a CI/CD environment, a VPS hosting multiple services, or a corporate Android smartphone, a kernel privilege escalation typically makes it possible to go from a restricted account to a full machine compromise. This includes access to all local data, the neutralization of security mechanisms, the installation of persistence, and, in some cases, lateral movement to other systems.

The exact CVSS score must be verified in the official advisory from the relevant vendor or maintainer. Media coverage mainly highlights the operational severity of the issue and the availability of fixes through Linux distributions and Android OEMs. In the absence, in the provided source, of a vendor bulletin precisely detailing all fixed branches and all version numbers, the factual recommendation is this: apply without delay the kernel updates published by your distribution or your Android provider, then reboot the affected systems.

For web and server environments, this vulnerability must be prioritized even if it is not remotely exploitable on its own. In practice, a local kernel flaw becomes an impact multiplier as soon as an attacker gains a foothold on the machine through a compromised web application, an exposed SSH account, a hijacked scheduled task, a poorly isolated container, or a post-exploitation chain after credential theft. That is precisely what makes this type of bug dangerous in modern infrastructures.

Affected versions

The initial coverage indicates that the vulnerability affects the Linux kernel and that an impact is also observed on Android. However, the secondary source provided does not, by itself, detail the exhaustive list of vulnerable and fixed versions for each kernel branch, each distribution, or each mobile manufacturer. In this context, it would be imprudent to invent a version matrix.

The factual elements that can be retained are as follows:

• Affected product: Linux kernel
• Impacted ecosystems: Linux server and desktop distributions, as well as Android via kernels integrated by OEMs
• Type of flaw: local privilege escalation from an unprivileged account to root
• Fix: a fixed version was published by the maintainers and then relayed by the relevant distributions and providers

In practice, to identify the affected versions precisely in your environment, you must rely on your provider’s official advisories:

• security bulletins for the Linux distribution in use
• tracking pages for the linux-image, kernel, or equivalent package
• Android security announcements and OEM bulletins
• possibly notices from CERT-FR if a monitoring or recommendation note is published

A few useful checkpoints on the Linux side:

• on Debian and Ubuntu, check the installed kernel with uname -r and then compare it with the fixed versions offered in the security repositories;
• on RHEL, AlmaLinux, Rocky Linux, Oracle Linux, or Fedora, check the update announcements for the kernel package;
• on SUSE and openSUSE, consult the maintenance and security bulletins associated with the kernel;
• on managed environments at OVHcloud, Scaleway, o2switch, or other French hosting providers, check whether the provided infrastructure includes a kernel managed by the customer or by the provider.

For Android, the operational reality is more fragmented. The fix may be available in an Android bulletin, but its actual deployment then depends on the manufacturer, the carrier, and the device’s update cycle. It is therefore necessary to distinguish between:

• the availability of the fix in the upstream Android ecosystem;
• its availability on the device actually in use;
• the actual installation of the update by the user or the MDM administrator.

In the absence of a consolidated and official list in the provided source, the rule of caution is simple: consider any Linux or Android system not yet updated with the fix published by its provider as potentially vulnerable.

Attack vector

CVE-2026-46242 is described as a local privilege escalation flaw. This means that an attacker must already have execution capability on the targeted machine, even with very limited rights, to attempt exploitation. In other words, based on the elements available here, this vulnerability is not a standalone network RCE-type flaw. Yet, in a server context, that does not necessarily reduce its real severity.

The term “Bad Epoll” suggests an issue related to the epoll subsystem, a core Linux component for efficient input/output event handling. epoll is widely used by web servers, reverse proxies, application runtimes, network intermediaries, and many infrastructure building blocks. When a memory handling, synchronization, or state validation error affects a kernel primitive at this level, the risk is that a local user may manipulate kernel behavior to escape their privilege boundary.

Without reproducing exploitation details not confirmed by the official advisory, the generic scenario is as follows:

• an unprivileged user runs a local program;
• this program interacts with kernel interfaces related to epoll;
• a faulty condition in the kernel makes it possible to corrupt an internal state or bypass a check;
• the attacker ultimately obtains execution with root privileges or equivalent control over the system.

In a web environment, the paths to this “local position” are numerous:

Post-exploitation after application compromise

A web application vulnerable to command injection, executable file upload, deserialization, or an RCE in a framework can give the attacker a shell under the service identity, for example www-data, nginx, apache, or a dedicated application user. If that account can then exploit a local kernel flaw, the compromise moves from an isolated container or service to full control of the host.

Multi-tenant and shared environments

In environments hosting multiple customers or multiple teams on the same machine, the boundary between local users is a strong security assumption. A local kernel flaw breaks precisely that assumption. On a shared platform, a malicious or compromised customer can potentially target the host or other workloads. This is particularly sensitive for:

• shared hosting;
• shared bastion hosts;
• build servers;
• CI/CD runners;
• compute nodes and university environments;
• PaaS and certain poorly segmented VPS offerings.

Containers and escape to the host

A container is not a full virtual machine; it shares the host kernel. That is why a Linux kernel vulnerability remains critical even if applications are “containerized.” If an attacker gains execution in a container with a low-privileged user, a kernel privilege escalation can open the way to a breakout, depending on the container configuration, the granted capabilities, the seccomp, AppArmor, SELinux mechanisms, and the state of the host kernel.

The risk is even greater if one of the following bad practices is observed:

• containers launched in --privileged mode;
• mounting the Docker socket into a container;
• adding unnecessary Linux capabilities;
• disabling security profiles;
• co-location of workloads with different trust levels on the same node.

Workstation and Android

On a Linux workstation or an Android device, local exploitation can be used to escape a sandbox, bypass separation mechanisms between applications, or obtain full administrative control after the initial execution of malicious code. Here again, the flaw is not “less serious” because it is local: it becomes a particularly powerful link in an attack chain.

Impact

The reported impact for CVE-2026-46242 is obtaining root privileges. On Linux, in practice, this means a near-total compromise of the affected system. The consequences depend on the machine’s role, but they generally include the following capabilities:

• reading and modifying all local files;
• access to application secrets stored on disk;
• potential reading of private keys, certificates, tokens, and passwords;
• disabling or altering security agents;
• installation of backdoors and persistence mechanisms;
• modification of local network rules;
• interception of traffic or inter-process communications;
• pivoting to other systems accessible from the compromised machine.

For a web server, a few concrete scenarios illustrate why a local kernel flaw should move very high in the patch queue:

LAMP/LEMP server compromised via a web application

An RCE in a PHP, Node.js, Python, or Java application makes it possible to obtain a shell under a restricted account. Without a local flaw, the attacker sometimes remains confined to the service perimeter. With a kernel privilege escalation, they can:

• access local databases or configuration files containing credentials;
• modify the web server or the OS to maintain access;
• steal deployment secrets;
• compromise other applications hosted on the same machine.

Kubernetes or Docker node

A compromised container on a vulnerable node can become the starting point for a host compromise. Once root on the host, the attacker can potentially:

• read mounted volumes and secrets;
• access other containers on the node;
• manipulate the container runtime;
• use the machine as a stepping stone into the cluster.

Shared environment or shared bastion host

A simple user account, even without administrative privileges, may be enough to launch the exploit. In a shared environment, this calls into question the separation between customers or between teams. For a hosting provider or service provider, the risk is then no longer merely individual but systemic.

In terms of prioritization, a local kernel privilege escalation should often be treated as critical in context as soon as at least one of the following conditions is met:

• presence of multiple local users;
• hosting of workloads not fully under control;
• Internet exposure of applications that can provide an initial entry point;
• use of containers;
• a machine handling sensitive data or infrastructure secrets.

How to patch

The priority remediation is to install the fixed kernel version published by your Linux distribution or, on the Android side, to deploy the security update provided by the OEM. Since the kernel is affected, a reboot is generally required for the fix to actually become active.

The first step is to identify the currently loaded kernel:

uname -r

On common Linux distributions, the update commands are as follows.

Debian / Ubuntu

Update the package index and then install the available security updates, including the kernel:

sudo apt update
sudo apt full-upgrade -y

Depending on your distribution’s policy, it may also be useful to check the installed kernel packages:

dpkg -l | grep linux-image

After installing the fixed kernel published by the vendor, reboot:

sudo reboot

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

On distributions using dnf:

sudo dnf upgrade --refresh -y

On some older environments still using yum:

sudo yum update -y

Then check the installed versions of the kernel package, and reboot to load the fixed version:

rpm -qa | grep '^kernel'
sudo reboot

SUSE / openSUSE

sudo zypper refresh
sudo zypper update -y

Then reboot:

sudo reboot

Post-fix verification

After rebooting, confirm that the active kernel does indeed match the fixed version published by your provider:

uname -r

In high-availability environments, plan an appropriate deployment strategy:

• drain Kubernetes nodes before rebooting;
• fail over to a secondary node for stateful services;
• a coordinated maintenance window for hypervisors and shared hosts;
• compatibility verification with third-party kernel modules.

Android

For Android, there is no universal command comparable to apt or dnf, because deployment depends on the manufacturer. The correct action is to:

• check for the availability of a system update in the device settings;
• check the Android security patch level;
• apply the OEM update as soon as it is offered;
• force deployment via MDM/EMM if the device is enterprise-managed.

For professional mobile fleets, it is important to distinguish between devices that are still supported and those that no longer receive fixes. An unmaintained Android device remains exposed even if the fix exists in the upstream ecosystem.

Detection

Since this is a local privilege escalation in the kernel, detection is not always straightforward. Many local exploitations leave few obvious application traces, especially if the attacker cleans up afterward. It is therefore necessary to combine several levels of observation: version inventory, system telemetry, security logs, process events, and signs of post-exploitation compromise.

1. Inventory potentially vulnerable systems

The first risk indicator remains identifying hosts running an unpatched kernel. On Linux:

uname -r

Across an environment, this check should be industrialized via your usual tools: configuration management, EDR, CMDB, cloud inventory, vulnerability scanner, or simple collection via automated SSH.

Points to watch:

• the presence of the fixed package is not enough if the machine has not rebooted;
• in containers, uname -r reflects the host kernel;
• in virtualized environments, the vulnerable kernel is the VM’s, not the hypervisor’s, except in particular cases.

2. Look for abnormal privilege escalations

A successful exploitation may result in unexpected processes running as root, the appearance of new accounts, modifications to system files, or configuration changes. A few investigation paths:

• creation or modification of accounts in /etc/passwd, /etc/shadow, /etc/sudoers;
• addition of SSH keys in /root/.ssh/authorized_keys or in service accounts;
• appearance of unusual setuid binaries;
• persistent services added in systemd, cron, or initialization scripts;
• loading of unexpected kernel modules;
• disabling of logs or security agents.

Examples of useful checks:

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. Review system logs

Depending on the exact nature of the bug and how it is exploited, traces may appear in journalctl, syslog, audit logs, or EDR traces. In particular, you should monitor for:

• unusual kernel crashes or anomalies;
• short process sequences launched by a service account and then followed by root actions;
• events involving local execution from temporary directories;
• post-exploitation behavior after web compromise.

Examples of commands:

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

If auditd is enabled, it can help reconstruct an execution chain. Otherwise, the absence of detailed telemetry should be considered a blind spot to be corrected.

4. Correlate with signs of application compromise

Because a local kernel flaw often comes after an initial compromise, the investigation must be correlated with web logs, authentication events, and EDR alerts. A few contextual IoCs, not specific to a particular exploit but relevant in an investigation:

• execution of system commands by the web server account;
• files dropped in /tmp, /dev/shm, or upload directories;
• unexpected child processes launched by php-fpm, apache2, nginx, node, python, or java;
• unusual outbound connection from a web server;
• rapid permission changes on system files;
• abnormal use of compilers or tools such as gcc, clang, make on production servers where they should not be present.

Examples of searches:

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

5. Android: monitoring and governance

On Android, detection depends more on MDM/EMM tools, mobile defense solutions, and the level of available logging. The key points are:

• inventory of the security patch level;
• identification of unsupported devices;
• correlation with the installation of unapproved applications;
• monitoring of compromise indicators reported by fleet management tools.

In case of suspected successful exploitation, the response must be treated as a full compromise of the device.

Mitigation

The kernel fix remains the only durable response. When a patch cannot be applied immediately, mitigation measures mainly aim to reduce exploitation opportunities and to limit the impact of initial local access. They do not replace the update.

Reduce local exposure

• disable or suspend non-essential shell access;
• restrict interactive service accounts;
• remove obsolete users;
• limit SSH access to authorized administration addresses only.

Example of shell account control:

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

Harden containerized workloads

• avoid --privileged;
• remove unnecessary Linux capabilities;
• apply seccomp profiles;
• enable AppArmor or SELinux depending on the distribution;
• separate risky workloads onto dedicated nodes.

These measures do not fix the kernel, but they can complicate an exploitation chain or reduce the surface accessible from a compromised container.

Limit tools useful to a local attacker

On production servers, it is often relevant to remove compilers and build tools when they are not necessary. Many public exploits for local flaws are provided as code to be compiled locally. The absence of a compilation toolchain does not prevent all attacks, but it can slow down an opportunistic adversary.

Strengthen monitoring

• enable or strengthen auditd;
• monitor temporary directories;
• detect executions from /tmp and /dev/shm;
• correlate service account actions with privilege events.

Segment and isolate

On shared or multi-tenant platforms, if the update cannot be immediate, stronger temporary measures should be considered:

• reduce the number of tenants per host;
• move the most sensitive workloads;
• temporarily disable certain customer access;
• prioritize hosts exposed to the Internet or receiving untrusted code.

For Android in the enterprise, a realistic mitigation is to block access to sensitive resources from devices that have not yet received the fix, via MDM policies, conditional access, or network segmentation.

Why a local kernel flaw remains critical in production

The most important point of this alert may be this: a local flaw in the kernel is not a “secondary” issue reserved for workstations. In modern server environments, it is often the element that turns a limited incident into a major compromise.

Three operational realities explain this:

• intrusions rarely start directly as root: the attacker first gains partial access, then seeks to extend it;
• the kernel is the ultimate boundary: if it falls, application separation mechanisms lose a large part of their value;
• infrastructures are densified: containers, shared environments, CI/CD, PaaS, and shared nodes increase the impact of a local escalation.

That is why Linux administrators should generally prioritize this type of flaw on:

• Internet-exposed servers;
• container hosts;
• shared environments;
• bastion hosts;
• systems hosting infrastructure secrets;
• administration workstations;
• still-supported corporate Android devices.

The initial media source is The Hacker News, which relays the existence of CVE-2026-46242 and its impact on Linux and Android. For operational action, the best practice remains to then rely on the official bulletins from Linux distributions and Android OEMs, because they are the ones that publish the fixed versions, the availability schedule, and the exact deployment procedures.

If your organization operates Linux servers for web applications, container nodes, or shared environments, the immediate priority is to check the active kernels, apply the available security updates, and reboot the affected hosts. At the same time, a review of post-exploitation traces and persistence mechanisms is recommended on the most exposed machines. To durably strengthen resilience, deeper work on system hardening, privilege reduction, and workload isolation remains essential; additional hardening measures can be found in the category /categorie/pratiques.