HIGH: Bad Epoll Linux Kernel Zero-Day Hands Any Local User Root, Reaches Android

Every so often a bug comes along that reminds you the most dangerous code is the code nobody thought to look at twice. Bad Epoll is that bug. Tracked as CVE-2026-46242, it is a race condition in the Linux kernel that lets a completely unprivileged user climb all the way to root, and it does not stop at servers and desktops. It reaches Android too, which means the same primitive that owns a cloud host can, in principle, own the phone in someone's pocket. Security researcher Jaeyoung Chung disclosed it through Google's kernelCTF program, and the exploit he built hits root roughly ninety nine percent of the time on a vulnerable machine. That is not a lottery ticket. That is a skeleton key.

The severity rating on paper is a CVSS score of 7.8, which lands it firmly in High territory rather than Critical, and there is a reason for that. This is not a remote code execution bug that lets an attacker in from the internet. An attacker already needs a foothold, some way to run code as an ordinary local user, before Bad Epoll matters. But that caveat is doing less work than it sounds like, because getting an ordinary user account on a modern system is often the easy part. A compromised web application, a malicious npm package, a phishing payload, a hostile browser tab, any of these gives you exactly the low privilege starting point this flaw needs. Bad Epoll is the second half of the sentence, the part where a nuisance foothold becomes total control of the box.

The flaw lives in epoll, one of the most heavily used pieces of the Linux kernel. Epoll is the mechanism that lets a program efficiently watch thousands of file descriptors and network connections at once, which is why it sits underneath basically every high performance server, database, and browser you can name. The bug itself is a use after free triggered by a race. Two separate paths inside the kernel try to clean up the same internal object at the same moment. One path frees the memory while the other is still writing into it, and in that split second of overlap an attacker can corrupt kernel memory in a controlled way. From there the path to root is well trodden. Corrupt the right structure, hijack execution, and the kernel hands you the keys.

What makes this one nasty is how the researcher solved the reliability problem that usually keeps race conditions academic. The window where the two code paths collide is only about six machine instructions wide. In practice that is a needle in a haystack, the kind of timing window that fails ninety nine times out of a hundred and gets written off as impractical. Chung's contribution was an exploitation technique that widens that window until the odds flip completely, turning a theoretically exploitable race into one that succeeds almost every single time. This is the recurring story of modern kernel security. The bug is rarely the whole threat. The weaponization is.

There is a genuinely interesting wrinkle in how this came to light. Both Bad Epoll and a closely related sibling bug trace back to the same 2023 change to the epoll code, a single well intentioned commit that quietly introduced two separate flaws. The first of the pair, now tracked as CVE-2026-43074, was actually discovered earlier in 2026 by an AI model and patched. The kernel got cleaned up, everyone moved on, and the second bug sat right next door in the same stretch of code, unnoticed, until a human researcher went looking and found it. If you needed a tidy illustration of why automated auditing and human review are complements rather than substitutes, this is it. The machine caught one and walked right past its twin.

On the question of who is affected, the picture is a little muddy and worth stating carefully. The bug was introduced by that 2023 change, and the confirmed affected range points at kernel version 6.4 and newer running without the fix. Some trackers list a wider window stretching back further, so the safe assumption for any given system is that if you are on a modern kernel and have not applied a recent update, you are exposed until proven otherwise. One useful data point from the disclosure is that Google Pixel 8 phones, which ship on a 6.1 based kernel, are not affected, which lines up with the idea that the vulnerable code arrived in later kernels. The Android exposure is the part that should make people sit up. On a phone, root by way of this bug means access to secure storage, credential keystores, and a clean escape from the application sandbox that is supposed to keep one app from touching another. The researcher demonstrated the flaw can be triggered from inside a Chrome renderer sandbox, which is exactly the sort of low trust environment that is supposed to contain hostile code, not launch it toward the kernel.

Here is the good news, such as it is. As of disclosure there is no evidence of exploitation in the wild. Bad Epoll is not on CISA's Known Exploited Vulnerabilities catalog, and the only working code that exists is the kernelCTF proof of concept, with a full Android exploit still in development. That is a window, and it is the kind of window you should treat as closing fast, because public proof of concept code has a way of maturing into commodity exploitation on a timeline measured in weeks. The upstream fix has landed, carried in commit a6dc643c6931, and the major distributions are expected to ship backported patches through their normal channels. For Android, the fix will arrive through the monthly Google Android Security Bulletin and the over the air updates that follow, which as everyone painfully knows can lag by weeks or months depending on the device maker.

The frustrating reality is that there is no workaround. Epoll is not an optional module you can disable or a service you can firewall off. It is load bearing infrastructure baked into how Linux does asynchronous input and output, so nobody is turning it off to buy time. That leaves patching as the only real answer. The practical move is to inventory every Linux system you run, prioritize the multi tenant ones where untrusted users share a kernel, container hosts, shared build servers, hosting environments, anything where the local user boundary is the security boundary, and roll the vendor kernel updates as soon as they clear your testing. For fleets of Android devices, lean on your mobile device management to force the security patch level forward the moment the bulletin drops rather than trusting users to update on their own schedule.

On detection, do not expect a clean signature, because a successful exploit lives entirely in kernel memory and does not announce itself. What you can watch for is the noise around it. Unexpected privilege transitions, processes that suddenly acquire root without a legitimate path to get there, kernel oops messages or crashes clustered around epoll operations, and unusual local process behavior on systems where you have good endpoint telemetry are all reasonable tripwires. Kernel level exploits are loud in the ways they fail and silent in the ways they succeed, so hunting for the failed attempts, the crashes and the anomalies, is often more productive than looking for the clean kill.

For managed service providers, Bad Epoll is a textbook moment to have the patch cadence conversation with clients before the exploit matures rather than after. A vulnerability that turns any low privilege foothold into full compromise is exactly the argument for managed patching, prioritized vulnerability remediation, and mobile device management as recurring services rather than fire drills, and it pairs naturally with an endpoint detection and response upsell for the customers who want eyes on the anomalous behavior a kernel exploit leaves behind. The pitch writes itself. The clients who patch on a schedule sleep through this one, and the clients who do not become the case study.