On a fully patched Linux desktop, any user with a shell account can open a terminal, run a publicly available exploit, and be root within seconds. The vulnerability that makes this possible is called Bad Epoll, assigned CVE-2026-46242, and it sits in a component of the Linux kernel that cannot be disabled. Security researchers at Google's kernelCTF programme published a working exploit. The fix is a single upstream commit. But the path from vulnerable to patched depends on distribution backyards that have their own timelines.
The researcher who found Bad Epoll is Jaeyoung Chung. His exploit reaches root approximately 99 per cent of the time on tested systems. It works inside Chrome's renderer sandbox, which blocks almost every other known kernel privilege-escalation technique. It reaches Android. And it was found six months after an AI model from Anthropic, Mythos, found a sibling vulnerability in the same 18 lines of code and missed this one.
Epoll is a Linux kernel mechanism for efficient I/O multiplexing. It allows a program to watch many file descriptors simultaneously and be notified only when one of them becomes ready for reading or writing, rather than polling each one in turn. Web servers, databases, network services, and modern desktop applications all use it. Nginx, PostgreSQL, and the Chromium browser engine all rely on epoll for their core event loops. It is not an optional feature; it is woven into the event-driven architecture of essentially every high-performance application on Linux.
The inability to disable epoll is relevant because it means there is no defensive configuration that removes the attack surface. A vulnerability in, say, a specific kernel module for a peripheral device can be mitigated by unloading that module on systems that do not need it. There is no equivalent action available for epoll. Any system running a current Linux kernel with a shell-accessible user is exposed until the patch is applied.
Bad Epoll is a use-after-free vulnerability. The class refers to situations where a piece of memory is freed, releasing it back to the kernel's allocator, while another part of the code still holds a reference to the same memory and continues to use it. If the allocator reuses that memory before the second user finishes with it, both users are now writing into the same location simultaneously. The result is memory corruption whose consequences depend on what the allocator placed in the recycled memory and what the remaining user writes into it.
In Bad Epoll, two code paths in the epoll subsystem attempt to clean up the same internal object. One path frees the object's memory. The other path is still writing into it. The collision is a race condition: the dangerous state only exists for a window of approximately six machine instructions, the brief overlap between the first path's free and the second path's write. Most of the time, the two paths do not reach that point simultaneously. Most of the time is not all of the time.
Chung's contribution was to widen that window. His exploit uses specific kernel scheduling techniques to make the two paths more likely to overlap, turning what would otherwise be a rare coincidence into a near-certain outcome. On systems he tested, the exploit reaches root roughly 99 per cent of the time. It does so without crashing the system, which is significant: a privilege escalation that reliably destabilises the target is less operationally useful than one that leaves the machine running and the attacker quietly elevated.
Chrome's renderer sandbox is one of the most significant security controls in modern desktop computing. It isolates the renderer process, the component that parses and executes web content, behind a tight system-call filter using seccomp-BPF. Code running in the renderer cannot make most kernel calls directly. If a malicious web page exploits a rendering bug and achieves code execution inside the renderer, it is still contained: the attacker controls the renderer process but not the broader system.
Most kernel privilege-escalation vulnerabilities cannot be triggered from inside the renderer sandbox, because the system calls they require are blocked by the seccomp filter. Chung reports that Bad Epoll is an exception. The epoll system calls it relies on are not blocked by Chrome's renderer sandbox, because they are needed for legitimate rendering operations. This means an attacker who compromises the renderer through a web content vulnerability can chain Bad Epoll to escape the sandbox and reach the underlying operating system.
The implications are significant for browser-based attack chains. A full browser exploit chain typically requires two separate vulnerabilities: one to execute code inside the renderer, and one to escape the sandbox and achieve privilege escalation. Bad Epoll provides the second component for a wide range of potential renderer bugs. An attacker with a renderer zero-day does not need a separate kernel bug as long as Bad Epoll remains unpatched on the target.
Most Linux kernel privilege-escalation vulnerabilities do not reach Android. The Android kernel is a heavily modified fork that does not track upstream Linux closely, and many bugs in the upstream kernel are either absent or patched separately by the Android security team before researchers publish details.
Bad Epoll is unusual in this respect. Chung reports that it affects Android as well as Linux desktops and servers, with one significant caveat: the Android-specific exploit is still in development as of the time of writing. Kernels based on version 6.1, including those found in devices such as the Pixel 8, are not affected because the vulnerability was introduced in a 2023 change to the epoll code that landed in kernel version 6.4. Devices running 6.4 or later are affected unless the fix has been applied.
On Android, privilege escalation from a sandboxed application or a compromised system service has implications that differ from the Linux desktop case. Android's security model relies heavily on process isolation and per-app privilege separation. An attacker who achieves root through Bad Epoll on an Android device can access data belonging to any application, disable security software, install persistent implants, and bypass the secure boot chain. The Android Security Bulletin process is the relevant patch channel, but the timeline between upstream fix and over-the-air update delivery to individual devices varies widely by manufacturer.
Bad Epoll sits in the same small section of kernel code where Anthropic's Mythos model recently found a different vulnerability, now tracked as CVE-2026-43074. Anthropic has separately noted that Mythos found Linux kernel privilege-escalation bugs, though the company has not publicly linked that work to this specific code section. Both vulnerabilities trace back to a single change made to the epoll implementation in 2023. Mythos caught one of the two. It missed the other.
Chung offers two reasons, and is careful to say neither can be confirmed without knowing exactly what the model was shown. First, the timing window for Bad Epoll is extremely narrow, approximately six machine instructions, making the exact sequence of events difficult to reason about even when looking directly at the code. Tracking a race condition requires simultaneously holding the state of two execution paths in mind across the window where they can overlap. This is something human reviewers frequently miss and that requires explicit instrumentation, such as the KASAN kernel sanitiser, to catch at runtime.
Second, once CVE-2026-43074 was patched, Bad Epoll's memory corruption usually fails to trigger KASAN, the kernel's primary memory error detector. There is nothing at runtime that flags the problem as existing. The bug is present in the code, but without the specific sequence of events that produces it, no signal propagates to a developer or an auditing system. A reviewer looking at the code after the first fix, whether human or AI, sees patched code that behaves normally under typical test conditions.
The broader point for security teams is not that AI is unreliable, but that race-condition vulnerabilities in shared kernel subsystems are particularly difficult to find with any automated method. They require reasoning about timing properties that are not explicit in the code, and they tend not to trigger detectors during ordinary execution. Manual review by a specialist with deep kernel knowledge and access to timing analysis tools is still the most reliable method for catching this class of bug.
The fix for Bad Epoll is upstream commit a6dc643c6931 in the mainline Linux kernel tree. Distributions including Debian, Ubuntu, Red Hat, and SUSE have been backporting the fix to their supported kernel versions. The relevant question for any specific deployment is whether the running kernel version includes this commit or the distribution's equivalent backport.
Kernels built on version 6.4 or newer are affected unless the commit is present. Older 6.1-based kernels are not affected because the 2023 change that introduced the bug post-dates their codebase. For most enterprise Linux deployments running a current distribution kernel, the relevant check is to compare the installed kernel version against the distribution's security advisory for CVE-2026-46242 and apply the available update.
Bad Epoll is not on the CISA Known Exploited Vulnerabilities list as of this writing, and Chung reports no signs of exploitation in the wild. The only public working exploit code is the kernelCTF proof of concept, which Chung submitted through a responsible disclosure process. The Android version of the exploit remains in development. The risk calculus for patching priority is therefore different from a vulnerability that is actively being used in attacks. But the technical properties, 99 per cent root reliability, Chrome sandbox escape, and Android reach, make this a vulnerability that attacker toolkits will incorporate once a working Android implementation is published.
Bad Epoll follows a pattern that has produced several high-severity Linux kernel bugs over the past two years: a modification to a concurrency-sensitive subsystem introduces a race condition whose window is too small to trigger consistently in testing, too small for automated sanitisers to catch, and too small for reviewers to spot without explicit timing analysis. The same 2023 epoll change produced two separate vulnerabilities. Neither was caught during code review at the time of the commit. One was found by an AI model. The other was found by a human researcher six months later.
For security teams managing Linux infrastructure, the lesson is not that AI-assisted code review has failed, but that race conditions in kernel concurrency code require a specific kind of scrutiny that even sophisticated automated systems do not yet provide reliably. The kernel's own sanitisers, KASAN and KCSAN (the kernel's concurrency sanitiser), are important tools, but they require the race to actually occur during instrumented execution. A race with a six-instruction window may simply never fire during a test run, even an extended one.
The practical response is to maintain a patching cadence that includes kernel updates and to monitor distribution security advisories for CVE-2026-46242 specifically. Organisations running Android device fleets should watch the Android Security Bulletins for a patch that addresses this CVE and enforce its deployment through their mobile device management platform as soon as it becomes available.
Bad Epoll is not an isolated case. The Linux kernel has seen a series of high-severity race-condition vulnerabilities over the past two years, several of them in subsystems that share epoll's characteristic of being both widely used and sensitive to concurrent access patterns. CVE-2025-0851, a use-after-free in the io_uring subsystem, was exploited in real attacks before a patch was available. CVE-2024-50264, a race in the vsock subsystem, allowed container escapes in Kubernetes environments. The pattern that unites these vulnerabilities is the same as Bad Epoll: a timing window too narrow to catch in ordinary testing, a correction that addresses one manifestation while leaving the underlying concurrency model intact, and a discovery-to-exploitation timeline that measured in months rather than years.
What distinguishes Bad Epoll from most of this cohort is the Chrome sandbox escape capability. The Chrome renderer sandbox is one of the most mature process isolation mechanisms in production software. Google has invested substantial engineering effort in making it restrictive: the seccomp-BPF filter that governs the renderer process blocks the vast majority of system calls that kernel privilege-escalation exploits require. When Chung demonstrated that Bad Epoll can be triggered from inside the renderer, he identified something more significant than a typical LPE bug. He identified a kernel vulnerability that completes a full exploit chain from a web content bug to root access, with no additional privilege between the steps.
The security implications for web-facing infrastructure are significant. Servers running web applications that use Chromium-based headless browsers for rendering, PDF generation, or screenshot services, a common pattern in SaaS platforms and content management systems, run renderer-equivalent code on server infrastructure. If that infrastructure runs an affected kernel, a server-side rendering engine represents an attack path from a web content injection vulnerability to root access on the server. This is not a commonly-considered attack surface in application security assessments, which tend to treat the browser process as a black box. The Bad Epoll disclosure changes that calculus.
The Android patching timeline for a kernel vulnerability like Bad Epoll is substantially more complex than the Linux distribution patching timeline. In the Linux ecosystem, once an upstream commit like a6dc643c6931 lands in the mainline kernel tree, distributions begin backporting it to their supported kernel versions. A typical enterprise distribution like Red Hat Enterprise Linux or Ubuntu LTS has security updates available within days to weeks of an upstream fix landing. Users apply the update through their package manager and the exposure ends.
Android follows a different path. The upstream Linux kernel fix must first be incorporated by Google into the Android Common Kernel, then backported by Google into the kernel versions used by its own devices (Pixel phones), then made available to other device manufacturers through the Android Security Bulletin. Device manufacturers, sometimes called OEMs, then integrate those patches into their own Android builds, test them, and release them as over-the-air updates. At each step, there is a delay. Larger manufacturers with mature security teams complete this process within one to three months of the Google patch. Smaller manufacturers with less investment in software maintenance may take six months or never deliver the patch for older devices.
The Android exploit for Bad Epoll is still in development as of this writing. That provides a window, but the window is not indefinite. Security researchers who are actively working on Android exploitation tend to publish their work through responsible disclosure channels, as Chung did with the Linux version, or through vulnerability markets. Once a working Android exploit exists and is published, the patching timeline for millions of devices that are still running affected kernels is measured in years, not months. Organisations managing Android device fleets through mobile device management platforms should treat CVE-2026-46242 as a high-priority item for patch deployment planning, both for current devices and for device procurement standards that specify minimum kernel version requirements.
Anthropic's Mythos model finding CVE-2026-43074, a sibling vulnerability in the same epoll code section, is significant evidence about the current state of AI-assisted vulnerability research. Race-condition bugs in kernel code are notoriously difficult to find through manual review and through automated analysis tools because they require simultaneous reasoning about two execution paths and the timing relationship between them. The fact that Mythos found one such bug in a 2023 epoll change is a genuine research result.
The fact that it missed Bad Epoll, in the same 18 lines of code, is equally informative. Chung's analysis of why the AI missed the sibling vulnerability points to two properties that race-condition bugs have in common: the timing window is not represented in the static code, and the bug does not produce a runtime signal under ordinary test conditions. These are properties that make a bug difficult for any analyser, human or automated, to find without specific instrumentation. The kernel's KCSAN tool, designed specifically to detect concurrency bugs at runtime, requires the race to actually fire during instrumented execution. For a six-instruction window, that may simply not happen during a test run of any practical length.
The implication for security teams using AI-assisted code review is not that AI is unreliable for kernel security. It is that AI is unreliable for a specific subcategory of kernel vulnerability that is also difficult for human reviewers and for automated runtime tools. Understanding where automation breaks down is more useful than a general statement about AI capability. Teams that use AI for security code review should pair it with KCSAN instrumentation for concurrency-heavy kernel subsystems, rather than treating AI review alone as sufficient for that class of bug.
Attackers who steal credentials, authentication tokens, or employee data do not sit on that material for long. They sell it, use it themselves, or both. Defendis monitors the underground markets, leak sites, and closed communities where that data surfaces, giving security teams advance warning before stolen access becomes a compromised account. If credentials belonging to your organisation appear after a browser-based theft, an OAuth token heist, or a phishing campaign, Defendis surfaces the exposure so your team can act before the attacker does. Learn how early detection changes incident outcomes or request a tailored briefing for your organisation.
