Cloud Security

Bad Epoll CVE-2026-46242: Every Linux Cloud Host Is Exposed

July 9, 2026 · 10 min read · By CloudAI Security
Bad Epoll CVE-2026-46242: Every Linux Cloud Host Is Exposed

Bad Epoll (CVE-2026-46242) is a use-after-free in the Linux kernel’s epoll subsystem, rated CVSS 7.8 (High). Reported on July 8, 2026 by researcher Jaeyoung Chung, it lets any unprivileged local user become root on Linux servers, desktops and Android, with a 99%-reliable public exploit and no disable switch.

Key points

  • CVSS 7.8 race-condition use-after-free in the kernel epoll subsystem, in the ep_remove() close path.
  • Introduced by a single 2023 kernel commit; affects kernel v6.4 and later, including every modern cloud VM and container host.
  • No module to unload: epoll is core kernel, so the only fix is a patched kernel or a livepatch.
  • Reachable from a web-tier process, a container, or even the Chrome renderer sandbox, with a 99% reliable public PoC.
  • A sibling bug in the same code (CVE-2026-43074) was found by Anthropic’s Mythos AI; Bad Epoll was not.

Bad Epoll (CVE-2026-46242) is the kind of vulnerability that should reset how cloud operations teams think about “local” privilege escalation. For the last decade the standard rebuttal to kernel LPE bugs has been: it needs a foothold first, so it is a second-stage problem. That framing has quietly stopped being true, and Bad Epoll is the clearest proof yet. The bug is reachable from any unprivileged process on a Linux box, including the worker behind a compromised WordPress plugin, a container that should be sandboxed, and even the Chrome renderer sandbox, which blocks almost every other kernel bug. There is no module to unload, no sysctl to flip, no kill-switch. The only remediation is a patched kernel or a livepatch, and the maintainers’ first attempt at a fix did not work. For a fleet of cloud VMs and shared-hosting boxes, this is a patch-now event, not a watch item.

What Bad Epoll Actually Is

CVE-2026-46242 is a race-condition use-after-free in the Linux kernel’s eventpoll subsystem, the high-performance I/O event notification facility that almost every networked process on a Linux system relies on. The flaw lives in the close path: two of epoll’s teardown routines can run concurrently and collide, with one path freeing a structure (ep_remove()) while the other is still writing into it, according to the oss-security disclosure by Jan Schaumann. That collision produces an 8-byte write into freed kernel memory, which the public proof-of-concept builds into arbitrary kernel memory access and, ultimately, a root shell.

The bug was introduced by a single kernel commit in 2023 (58c9b016e128) that, remarkably, planted two separate critical race conditions into roughly 2,500 lines of epoll code. One became CVE-2026-43074; the other is Bad Epoll. The CVE entry rates it CVSS 7.8 (High), with High confidentiality, integrity and availability impact, local attack vector, low complexity, low privileges required, and no user interaction. Affected versions span kernel 6.4 and later, which covers essentially every currently-supported cloud image from the major hyperscalers.

Why There Is No Kill-Switch

Most kernel privilege-escalation bugs that have dominated recent patch cycles, including the Copy Fail family, ship in loadable modules. If you cannot patch immediately, you can often unload the module and neutralize the attack path while you schedule a reboot. Bad Epoll removes that option. Epoll is a core kernel facility, not a module, and the operating system, network services, container runtimes, and browsers all depend on it. There is nothing to blacklist and no sysctl to harden; the only path to safety is a patched kernel or an in-memory livepatch that modifies the running kernel without a reboot.

This is why the CloudLinux advisory treats the bug as a server-class event rather than a generic CVE. On CloudLinux 9 and 10, and by extension any shared-hosting or multi-tenant Linux platform, the absence of a kill-switch means a single compromised tenant cannot be contained by configuration alone; the kernel itself is the boundary that fails.

The Cloud Reality: Local Means Compromised

The word “local” in the CVE metadata is the part cloud teams most often misread. Local does not mean a trusted insider or a customer you have vetted. On a multi-tenant host it means any process running on the machine, and in 2026 the realistic entry points are everywhere: a PHP-FPM worker behind a vulnerable plugin, an outdated CMS, a misconfigured container that let an attacker drop a payload, or leaked credentials that handed someone a shell. Once an attacker has any unprivileged code execution on the box, Bad Epoll is the bridge from “one site popped” to “the whole server owned.”

For shared-hosting providers the kill chain is brutally short. The CloudLinux team describes it directly: a web-tier compromise runs as the site’s identity, theoretically confined by CageFS; Bad Epoll turns that confined process into root, after which every tenant’s files, databases, credentials and backups are in reach, and recovery means rebuilding the entire server rather than cleaning one site. On Kubernetes node pools the geometry is similar: a pod compromise that should be contained by the container runtime can escalate to node root, which is the prerequisite for every meaningful container-escape technique that follows.

99 Percent Reliable, From a Sandbox

Two properties make Bad Epoll unusually dangerous in practice, and both are documented in the researcher’s own writeup. First, the race window is tiny, only about six instructions wide, so a naive attempt almost never lands; but the exploit widens that window and runs a retry loop that never crashes the kernel, achieving roughly 99% reliability on a 6.12 kernel. A 99%-reliable kernel root exploit with a public PoC is not a theoretical risk; it is operational certainty for any attacker who reaches the trigger.

Second, Bad Epoll is one of the few kernel bugs that can root Android. Most Linux privilege-escalation flaws, including Copy Fail and its variants, depend on modules that Android never loads. Out of roughly 130 vulnerabilities exploited on Google’s kernelCTF program, only about ten are realistic Android-root candidates, and Bad Epoll is among them. It can also be triggered from inside Chrome’s renderer sandbox, which blocks nearly every other kernel bug, meaning a browser exploit could chain with Bad Epoll to reach kernel code execution, the exact pattern Project Zero demonstrated in its MSG_OOB research. The researcher, Jaeyoung Chung of CompSec Lab at Seoul National University, submitted it as a zero-day to Google’s kernelCTF program, which rewards a qualifying Linux kernel exploit with over $71,337.

The Patch Took Two Months

Disclosure hygiene on this one is worth noting because it changes how aggressively you should hunt for exposure. The CVE was published on May 30, 2026, a public proof-of-concept landed around July 5, and the first news coverage followed within days. But the maintainers’ first patch did not fully fix the issue, and a correct patch landed only about two months after the bug was first reported. That is an unusually long window for a kernel that normally handles security issues with urgency, and it means there was a real interval during which a patched-looking kernel was still vulnerable.

The fix shipped as a set of stable commits, including 2de4db145b299 and 9324de74a3a5 in the stable tree. For anyone who applied the first, incomplete fix and moved on, re-verification is not optional.

What AI Missed

Bad Epoll also carries an uncomfortable lesson for the “AI will find every bug” thesis. Anthropic’s AI system, Mythos, examined the same epoll code path and did surface a sibling race condition, CVE-2026-43074, fixed through an RCU grace-period delay. That result alone was notable because kernel race bugs are notoriously hard to find. But Mythos missed Bad Epoll sitting in the same 2,500 lines. The likely reasons are instructive: the race window is only six instructions wide, so the exact thread interleaving is hard to reason about even when reading the vulnerable code, and after CVE-2026-43074 was fixed, Bad Epoll’s use-after-free usually did not trigger KASAN, the kernel’s main memory-error detector. Without that runtime signal, the model lacked the confidence to report it as a real bug.

The takeaway is not that AI vulnerability research is oversold, it is that it is probabilistic, and a single missed bug in a core subsystem can sit undetected for years. For a contrasting case where an AI system did surface an RCE-grade kernel flaw, see the OpenSSL PKCS7_verify AI discovery. Treat automated findings as a floor on coverage, not a ceiling, and assume that high-value, hard-to-trigger races are still the province of skilled humans for now.

The Cloud Ops Action Plan

For cloud and security operations, the response is concrete and time-boxed:

  1. Inventory kernel versions now. Run uname -r across every Linux host, container node, and cloud VM. Anything below the patched commits for the 6.4+ line is exposed. Do not assume your golden images are current; two-month patch gaps and incomplete first fixes mean image provenance checks matter.
  2. Patch or livepatch, do not configure around it. There is no sysctl, no module unload, no seccomp profile that reliably blocks Bad Epoll because epoll is core kernel. Roll the patched kernel, or apply a livepatch (KernelCare, kpatch, or your distro’s equivalent) to running hosts you cannot reboot. For CloudLinux 9/10 fleets, the CloudLinux advisory confirms a KernelCare livepatch is in the pipeline for the main feed.
  3. Tighten the preconditions, not the bug. Since the trigger is any unprivileged local process, reduce blast radius at the layer above: harden web tiers, keep CMS and plugin stacks current, enforce least-privilege on container workloads, and treat any pod-level compromise as a potential node compromise until the node kernel is patched.
  4. Assume container boundaries are weaker than they look. A root-on-node outcome turns most container-escape primitives into viable techniques. Re-baseline your node-hardening posture (read-only root filesystems, restricted seccomp profiles, dropped capabilities) as compensating controls, while the kernel patch is the real fix.
  5. Hunt for prior exploitation. The two-month window between report and correct fix, plus the public PoC since early July, means look-back matters. Check for unexpected root-level process lineage, new SUID binaries, and anomalous kernel module or memory manipulation on hosts that were internet-exposed or multi-tenant during the window.

Bad Epoll is the rare bug that is simultaneously a kernel engineering story, a cloud operations story, and a reality check on automated vulnerability research. The engineering is interesting; the operational consequence is not. On any multi-tenant Linux fleet, the gap between “a tenant got popped” and “the host is owned” is exactly one unpatched kernel. Close it.

References

Privacy Terms Contact