Researcher Jaeyoung Chung, a PhD candidate at Seoul National University’s CompSec Lab, has published a fully working exploit for a Linux kernel vulnerability nicknamed Bad Epoll. Tracked as CVE-2026-46242, the flaw lets an ordinary, unprivileged user gain full root control of a Linux machine, and it works on desktops, servers, and Android devices alike. Chung reported the bug independently as a zero-day submission to Google’s kernelCTF programme and reports a 99 percent success rate against real targets.

How the exploit works

Bad Epoll is a race-condition use-after-free bug in the kernel’s epoll subsystem, the mechanism nearly every Linux network service relies on to monitor file descriptors efficiently. During a call to ep_remove, the kernel clears a reference to the underlying file and then continues operating on it inside a critical section. A concurrent reference-count drop on another thread can free that file, and the memory it occupied, while the removal routine still believes it holds a valid reference. The result is a write to freed memory that an attacker can steer to gain arbitrary kernel writes and, from there, root privileges.

The genuinely alarming part is reliability. A race window this narrow is normally only about six CPU instructions wide, meaning a naive attack would almost never win the race. Chung’s exploit widens that window and runs a retry loop that never crashes the target, producing a working root shell on the overwhelming majority of attempts. The bug is also reachable from inside Chrome’s renderer sandbox, a context that blocks nearly every other class of kernel vulnerability, which is part of why it drew Google’s attention in the first place.

A patch has existed since April

The single 2023 kernel commit that introduced this class of bug actually introduced two separate race conditions across roughly 2,500 lines of epoll code. The first was caught during code review by Anthropic’s Mythos and tracked as CVE-2026-43074, fixed earlier in the year. The second, Bad Epoll, was fixed in the mainline kernel on 24 April 2026. Any kernel based on Linux 6.4 or newer that has not pulled that specific fix forward remains vulnerable today, more than two months after the patch shipped upstream.

That gap matters because mainline fixes and distribution security updates are not the same event. Long-term-support kernels used by major Linux distributions need the fix backported and released as a point update, and that process routinely lags weeks behind the upstream commit landing. For teams tracking kernel versions by distribution release number rather than by patch content, this is precisely the kind of fix that is easy to miss.

Why this hits self-managed European infrastructure hardest

Organisations running workloads on managed platform services generally have kernel patching handled for them. The exposure concentrates on teams running their own Linux fleets: bare-metal and dedicated servers on providers like Hetzner and OVHcloud, self-managed Kubernetes nodes, CI/CD build agents, and any container host where the organisation, not the provider, owns the kernel patching cadence. That describes a large share of European engineering teams that chose self-managed infrastructure precisely for cost and sovereignty reasons.

A local privilege escalation bug is rarely the first step in an attack, but it is consistently the step that turns a minor foothold into full compromise. Any process that can run arbitrary code on a host, a compromised dependency, a malicious container escape attempt, or a web application vulnerability that allows command execution, can now be chained into full root access with a publicly available, highly reliable exploit.

What we recommend

• Check your running kernel version against the fix commit (a6dc643c6931) rather than relying on a distribution release number alone, since backport timing varies by vendor
• Prioritise patching build agents, CI/CD runners, and container hosts, since these systems routinely execute untrusted or third-party code by design
• Apply distribution kernel updates as soon as they are available, and confirm the update pipeline actually reaches self-managed bare-metal fleets, not just managed cloud instances
• Treat local privilege escalation exposure as part of your broader supply chain risk assessment, since it multiplies the impact of any other successful compromise
• Review kernel patching ownership across your infrastructure estate, since bare-metal and self-hosted environments do not receive automatic kernel updates the way managed platforms do

If your organisation runs self-managed Linux infrastructure and needs help auditing kernel patch levels, building a reliable patching pipeline across bare-metal and cloud fleets, or assessing exposure to privilege escalation chains, contact Excello Digital. We help European DevOps and security teams close the gap between a published fix and a patched production environment.