Bad Epoll CVE-2026-46242: The Linux Kernel Vulnerability That Gives Root Access With 99% Reliability and Also Hits Android

On 3 July 2026, researcher Jaeyoung Chung, a PhD student at Seoul National University's CompSec Lab, published the full analysis of Bad Epoll (CVE-2026-46242), a use-after-free race condition vulnerability in the Linux kernel's epoll subsystem that allows any local unprivileged user to escalate to root with approximately 99% reliability. The flaw affects Linux servers, desktops and Android devices running kernel v6.4 or above. No workaround exists because epoll cannot be disabled: it is built into the core of how Linux handles network concurrency and is used by virtually every high-performance network service, runtime and web browser. Chung submitted the vulnerability as a zero-day to the Google kernelCTF programme, which rewards working exploits with over $71,000. The patch was merged into the kernel mainline (commit a6dc643c6931) in April 2026, but it sat there for months without many distributions shipping the backport, and the full public disclosure along with exploit code arrived only on 3 July — 70 days after the patch landed in mainline with no formal security announcement.

‍

What do we know about Bad Epoll (CVE-2026-46242)?

Facts documented by The Hacker News, SentinelOne, Breached.Company, The CyberSec Guru, Latest Hacking News and Chung’s own public repository:

• Vulnerability: use-after-free race condition in the ep_remove() function and its helper ep_remove_file() within the Linux kernel’s eventpoll subsystem. The function clears file->f_ep under a lock but continues using the @file pointer inside the critical section. A concurrent __fput() call can observe the transient NULL, skip eventpoll_release_file(), and free the watched struct eventpoll, producing kernel heap memory corruption.
• CVSS 7.8 (High): local attack vector, low complexity, low privileges required, no user interaction, high confidentiality, integrity and availability impact.
• Scope: Linux desktops and servers running kernel v6.4 or above, and Android devices. Pixel 8 (kernel v6.1) is not affected. Pixel 10 and devices running kernel v6.6+ should apply Google security updates as soon as available. The full Android exploit is not yet public, but Chung’s team has confirmed proof-of-concept memory corruption and is developing the complete chain.
• Exploit reliability: 99%. Winning a race condition reliably is normally the main obstacle in kernel exploitation. Chung’s design chains four linked epoll file descriptors —two pairs repeatedly trigger the race while others act as victims— and artificially widens the six-instruction window to achieve ~99% reliability without crashing the system.
• No workaround possible: epoll cannot be disabled. It is compiled into the kernel of any general-purpose Linux distribution (CONFIG_EPOLL is always enabled). No mitigation eliminates the attack surface; only the patch closes the hole.
• Exploit can fire from inside Chrome’s renderer sandbox: Bad Epoll is one of the few kernel bugs that can be triggered from Chrome’s renderer sandbox, significantly expanding exploitation scenarios beyond a local shell.
• Introduced by a 2023 commit: a single April 2023 change (commit 58c9b016e128) to the epoll code introduced two separate race conditions into roughly 2,500 lines of code. The first was found and fixed as CVE-2026-43074. Bad Epoll is the second and took additional months to surface.
• The AI angle: the same epoll code block where Bad Epoll hides was reviewed by Mythos, Anthropic’s AI model deployed under Project Glasswing. Mythos found CVE-2026-43074, the first bug, and an independent researcher later published a level-1 exploit for it on kernelCTF. But Mythos did not detect Bad Epoll. Chung offers two likely reasons: the race window is only six instructions wide, making the exact thread interleaving very hard to picture even while staring at the code; and once CVE-2026-43074 is fixed, Bad Epoll’s use-after-free does not usually trigger KASAN, the kernel’s main memory error detector, leaving no runtime signal that anything is wrong.
• No confirmed active exploitation: CVE-2026-46242 does not appear on CISA’s KEV catalogue as of publication, and no in-the-wild use has been reported. However, the exploit code is public, functional and highly reliable.
• Bug family: Bad Epoll joins the documented series of Android-rooting kernel bugs named “Bad”: Bad Binder, Bad IO_uring, Bad Spin, and now Bad Epoll. Of the roughly 130 exploits run through kernelCTF, only about ten are viable for rooting Android. Bad Epoll is one of them because epoll is not an optional module.

‍

Why a local Linux kernel vulnerability is a first-order risk for businesses

A local privilege escalation may seem less urgent than a remote RCE. In practice, for most real attacks, the opposite is true:

1. Local privilege escalation is the second step in almost every successful advanced attack. Threat actors rarely enter with administrator privileges directly. The typical pattern is low-privilege initial access —via phishing, web application exploitation, malicious npm package or any remote access vector— followed by LPE for persistence and lateral movement. With a local exploit that works 99% of the time on any Linux server, the gap between “limited access” and “full host control” closes almost deterministically.
2. Linux is everywhere that matters most: cloud servers, containers, CI/CD and Android. Bad Epoll’s attack surface is not a forgotten legacy server: it is the CI/CD runners where production code is compiled, the Kubernetes nodes serving critical applications, the multi-tenant servers where multiple customers coexist, and the hundreds of millions of Android devices in corporate employees’ hands. Initial compromise on any of these environments plus Bad Epoll equals full host control.
3. Multi-tenant and shared environments are the most critical scenario. On a multi-user server or a Kubernetes node where several workloads share a kernel, Bad Epoll turns a compromised low-privilege process —an exploited web application, a stolen CI token— into root over the entire host and, potentially, a container escape.
4. The exploit is public, reliable and can fire from Chrome. This is not a theoretical vulnerability: there is functional, well-documented code that achieves root with 99% reliability. And it can be triggered from Chrome’s renderer sandbox, meaning a malicious web page visited from a Linux server could be the entry vector.

‍

How the Bad Epoll exploitation chain works

1. Setup: chaining four linked epoll file descriptors. The low-privilege local attacker creates four specifically linked epoll instances. Two pairs repeatedly trigger the race while the others act as victims.
2. Triggering the race condition in ep_remove(). The function clears file->f_ep under a lock but continues using the pointer afterwards. A concurrent __fput() call can free the watched struct eventpoll while ep_remove() is still using it.
3. Memory corruption: eight-byte write into freed memory. Winning the race produces an out-of-bounds write into kernel heap memory, specifically into kmalloc-192 slab objects, and a misdirected kmem_cache_free() call against the wrong slab cache.
4. Control of a kernel file object. The attacker steers the corruption to take control of a struct file object in the kernel heap.
5. Arbitrary kernel memory read via /proc/self/fdinfo. With the file object under control, the exploit reads arbitrary kernel memory, obtaining the addresses needed for the next step.
6. ROP chain and root shell. The exploit builds a return-oriented programming chain to execute code in kernel context and spawns a root shell.

‍

Key lessons and available mitigations

Immediate action: patch the kernel

• Prioritise patching on internet-facing Linux servers, CI/CD runners, Kubernetes nodes and multi-tenant systems. The patch is available in commit a6dc643c6931 of the kernel mainline. Check whether the distribution in use has already published the backport; Debian has a repaired build in testing. Apply the patch and reboot.
• Inventory kernel versions across the entire Linux fleet. The flaw affects kernels v6.4 and above. Any host on an unpatched kernel version with local users or low-privilege processes is vulnerable.
• For Android devices: apply Google security updates as soon as available for the model. Pixel 8 (kernel v6.1) is not affected. The full Android exploit is not yet public, but proof-of-concept memory corruption code is.

Risk-reduction mitigations while patching

• Enable KASLR and SLUB randomization. These raise the technical exploitation bar because Chung’s race-widening technique depends on predictable heap layout. They do not eliminate the vulnerability but increase the required effort.
• SELinux or AppArmor in enforced mode. These can restrict what a successfully escalated process is permitted to do, though they do not prevent the escalation itself. Combined with the patch they represent the correct posture.
• Restrict low-privilege access to critical servers. Minimise the number of local users and processes capable of running code on servers where the impact of a successful LPE would be greatest.

Post-exploitation detection

• Bad Epoll leaves very few traces during exploitation because the race does not trigger KASAN. Detection should focus on post-exploitation symptoms: unauthorised new setuid binaries, unplanned sudoers modifications, new privileged accounts, boot configuration changes, or authentication events that immediately follow a known low-privilege compromise.
• Centralise kernel ring buffer and crash dump collection from Linux endpoints for retrospective analysis.
• Configure alerts for repeated soft lockups, RCU stalls or general protection faults originating in fs/eventpoll.c.

‍

Cybersecurity as a strategic priority

Bad Epoll is an uncomfortable reminder that the most reviewed code is not necessarily the most secure. A single 2023 commit introduced two race conditions into 2,500 lines of epoll code. A frontier AI model reviewed that code, found the first one, and missed the second. The second sat in mainline for three years before a human researcher, specifically looking for that class of bug, detected it. For security teams and organisations managing Linux fleets in production, today’s question is direct: do you know exactly which kernel version your servers, CI/CD runners and Kubernetes nodes are running, and how long has it been since you last applied kernel updates to avoid a reboot?

‍

Apolo Cybersecurity: kernel version auditing and patch prioritisation for Linux fleets

At Apolo Cybersecurity we help organisations manage the risk of kernel vulnerabilities like Bad Epoll: kernel version inventory across the entire Linux fleet, identification of priority systems for patching (multi-tenant servers, Kubernetes nodes, CI/CD runners), validation of backport status on distributions in use, assessment of the impact of an LPE on the organisation’s network architecture, and configuration of post-exploitation detection alerts in SIEM and EDR.

If you manage Linux servers and have no confirmation of which kernel version is in production and whether it includes the Bad Epoll patch, today is the time to verify it.

‍