Bad Epoll (CVE-2026-46242): Any Linux User Can Grab Root

A PhD student and a six-instruction timing window are why you should be running kernel updates this weekend. CVE-2026-46242, nicknamed "Bad Epoll," is a use-after-free race condition in the Linux kernel's epoll subsystem that hands any unprivileged local user a root shell — about 99% of the time, reliably, with a public exploit. The upstream fix landed on April 24, but the full technical writeup and working proof-of-concept went public on July 3–4, moving this from "patched in mainline" to "you need to act now."

What Epoll Does and Where the Bug Hides

Epoll is the Linux kernel mechanism that lets a single process efficiently watch for I/O events across thousands of file descriptors at once. Every serious server application — Nginx, Apache, MariaDB, Redis, PHP-FPM — depends on it. The vulnerability lives in ep_remove() inside fs/eventpoll.c. When two epoll objects are set to monitor each other and both are closed at nearly the same instant, one code path can free the underlying memory while the other still holds a stale pointer to it. That's a use-after-free.

Because struct file uses SLAB_TYPESAFE_BY_RCU, the freed slot can be recycled by a different allocator, turning the corruption into an attacker-controlled write against the wrong slab cache — corrupting kernel data structures that control privilege. The fix (commit a6dc643c6931) pins the file reference at the start of ep_remove() so concurrent teardown can't invalidate it mid-operation.

Jaeyoung Chung, a PhD researcher at Seoul National University's CompSec Lab, discovered the flaw, reported it through Google's kernelCTF program, and built a working exploit. The race window spans only six machine instructions, but Chung's four-file-descriptor chain widens it enough to succeed roughly 99% of the time on a vulnerable machine.

The AI Footnote Worth Noting

Anthropic's Mythos AI model caught CVE-2026-43074 — a nearby race condition in the same file — during an automated audit earlier this year. It missed Bad Epoll sitting right next to it. Two distinct privilege escalation bugs coexisting in the same 200-line function for years is the more uncomfortable observation.

Which Kernels Are Affected

The CVSS 3.1 score is 7.8 HIGH (vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — local access, low complexity, no user interaction, full C/I/A impact). The bug was introduced in April 2023 with commit 58c9b016. Per the NVD entry (published May 30, last modified July 4, 2026), affected ranges include:

• Linux kernel 6.4 through 6.18.32
• Linux kernel 6.19 through 7.0.9
• Stable branches 5.15.209 onward and 6.1.175 onward, where the vulnerable code was inadvertently backported

Not every 5.15 or 6.1 kernel is necessarily affected — it depends on whether your distribution backported the specific commit that introduced the bug. Canonical (Ubuntu), Red Hat, Debian, and SUSE have all been tracking this and are issuing kernel updates. Check your distro's security tracker and compare uname -r against the fixed kernel version in the advisory.

Why Web Servers Are Particularly at Risk

A CVSS 7.8 with a local access requirement can look reassuring if your mental model is "an outsider would have to break in first." Web environments routinely create local access in ways that aren't obvious:

• Shared hosting puts many customers on the same kernel. One user can try this against the machine they share with everyone else.
• Compromised web applications: if any app on the server has a shell injection, file write, or remote code execution vulnerability — including unpatched WordPress plugins — an attacker running as www-data can use Bad Epoll to become root. One bug chains into another.
• CI/CD and dev servers are frequently accessible to contractors or developers who have no business having root. They do now, if the kernel is unpatched.

As of this writing, Bad Epoll is not on CISA's Known Exploited Vulnerabilities catalog, and there's no confirmed in-the-wild exploitation. But a 99%-reliable public exploit changes the math. Attackers don't need to innovate; they need to find unpatched servers, and scanning is automated.

What to Do Right Now

• Identify your kernel version: Run uname -r on every Linux server. Cross-reference against your distribution's security advisory to confirm whether the patched kernel is already installed.
• Apply the kernel update and reboot: On Debian/Ubuntu: apt-get update && apt-get upgrade followed by a reboot. On RHEL/CentOS/Fedora: dnf update kernel and reboot. After rebooting, run uname -r again to confirm the new kernel is active — it's a common oversight to update without rebooting.
• Audit shell access while you wait: Review /etc/passwd and SSH authorized_keys; remove accounts and access grants you didn't issue. On some configurations, sysctl -w kernel.unprivileged_userns_clone=0 reduces the attack surface as a stopgap — it's not a patch.
• Take application-layer RCEs seriously: Bad Epoll is a reminder that a low-privilege foothold — a web shell running as www-data, say — can chain into full root when the kernel is unpatched. Fix your WordPress plugins too.

Falcon Internet runs kernel live-patch tooling and automated update pipelines on managed VPS environments — situations like this are exactly why the window between "working exploit published" and "first scanner sweep" should never be left open.