Bad Epoll is not just another critical Linux kernel vulnerability. It is an uncomfortable reminder for an industry that was starting to see artificial intelligence models as tools capable of finding almost any exploitable flaw in complex code. Reality is less convenient: even an advanced AI system can inspect a sensitive area of the kernel, find a serious bug, and still miss another one in the same code path.
The vulnerability, tracked as CVE-2026-46242, affects the Linux kernel’s epoll subsystem and was documented by security researcher Jaeyoung Chung. Its technical importance lies in the combination of two elements well known to low-level security teams: a race condition and a use-after-free. In simple terms, two execution paths manage the same internal object at the same time; one frees memory while the other is still using it. That small timing error can open the door to kernel memory corruption.
The case matters for three reasons. It affects a core Linux feature, it can allow local privilege escalation, and, according to the published research, it was missed by Mythos, Anthropic’s model used in Project Glasswing, even though the same model did find another race condition in the same area of code.
What epoll is and why it cannot simply be disabled
epoll is a standard Linux mechanism that allows an application to monitor many file descriptors or network connections efficiently. Web servers, browsers, network services, databases, runtimes and many modern applications rely on it to handle thousands of simultaneous events without blocking.
That is why Bad Epoll does not have a simple mitigation based on disabling a secondary module or turning off an optional feature. Unlike other kernel vulnerabilities tied to components that can be limited or removed in some environments, epoll is part of normal system operation. The real fix is to apply the upstream patch or the backport provided by each distribution.
According to the researcher’s technical repository, the vulnerability was introduced by a change in April 2023 and fixed in mainline with commit a6dc643c6931, published on 24 April 2026. Systems running kernels based on version 6.4 or later may be affected if they have not received the patch or an equivalent distribution-maintained fix.
The National Vulnerability Database describes the issue as a use-after-free in eventpoll, linked to the ep_remove function, where one execution path could continue using a structure while another had already freed or recycled its memory. It is not an easy bug to explain in one sentence, and that is part of its seriousness: concurrency bugs are often hard to detect, reproduce and fix correctly.
The bug Mythos missed
The most striking part of the case is not only the vulnerability itself, but the context around it. Anthropic introduced Project Glasswing in April 2026 as an initiative to use advanced AI capabilities to defend critical software, with partners including AWS, Apple, Google, Microsoft, NVIDIA, CrowdStrike, JPMorganChase, the Linux Foundation and other technology organisations. The company described Claude Mythos Preview as an unreleased model focused on finding and exploiting software vulnerabilities at a very high level.
That naturally created expectations. If a frontier model can audit critical code, generate hypotheses and find bugs that humans might miss, perhaps software security is entering a new phase. And it probably is. But Bad Epoll shows that this new phase does not remove the limits.
Chung’s write-up explains that a single 2023 commit introduced two separate race conditions into the epoll code, within a relatively small code path. Mythos reportedly found one of them, tracked as CVE-2026-43074, but missed Bad Epoll. The conclusion should not be that Mythos is useless. Finding an exploitable kernel race condition is already a serious achievement. The more useful reading is different: even when AI succeeds, it may not exhaust the full space of vulnerabilities.
The researcher points to two likely reasons. First, the race window was extremely narrow, only a few instructions wide. Second, after the other Mythos-discovered bug was fixed, Bad Epoll usually did not trigger KASAN, the kernel’s main dynamic memory-error detector. Without a clear runtime signal, the model may not have had enough confidence to report it as a real vulnerability.
That nuance matters. AI tools do not “see” the truth of a program in an absolute way. They reason from code, patterns, evidence, context and signals. If a bug depends on a very specific thread interleaving, leaves little runtime evidence and hides inside concurrent logic, the analysis becomes difficult even for very capable systems.
A reliable exploit in a tiny race window
Bad Epoll also reminds us that a small race window does not mean a small risk. According to the published analysis, the exploit expands the chances of hitting the vulnerable timing and retries without crashing the kernel, reaching close to 99% reliability on specific Google kernelCTF targets.
Google kernelCTF is part of Google’s vulnerability reward ecosystem and is designed for researchers to demonstrate exploitation techniques against Linux kernel vulnerabilities. Its rules include base rewards for exploits against LTS instances and bonuses for stability or 0-day submissions. That explains why the security community pays close attention to bugs that are not only theoretical, but exploitable in controlled conditions.
The potential impact is serious because this is local privilege escalation. Under the right conditions, an unprivileged local process could become root. In Linux desktops, multi-user servers, certain container environments or chained exploit scenarios, that changes the risk model. On Android, the researcher considers the bug especially relevant because epoll is available and does not depend on modules that many devices never load. Even so, this should be framed carefully: the repository states that the full Android exploit was still in progress, although the proof of concept already triggered the UAF on devices with kernel 6.6 or later.
For defensive teams, the practical recommendation is clear: check kernel versions, apply vendor updates and do not assume that the absence of crashes or KASAN alerts means the absence of risk. If a distribution uses kernel branches based on 6.4 or later, teams should verify whether it includes the upstream patch or a security backport.
The lesson: AI is necessary, but not enough
Bad Epoll arrives at a time when many organisations are integrating AI into code audits, vulnerability research, exploit generation in controlled environments, patch review and report triage. That makes sense. The ability of these models to read large codebases, connect patterns and accelerate hypotheses can reduce time and expand coverage.
But turning that support into a full replacement for human researchers would be a mistake. Kernel security, and software security in complex systems more broadly, still depends on intuition, experience, dynamic testing, fuzzing, manual review, concurrency modelling, knowledge of mitigations and the ability to turn a seemingly unlikely flaw into a real exploit.
AI can find vulnerabilities that a human team might take weeks to locate. It can also generate noise, overstate findings or miss bugs with weak signals. Human researchers can recognise impact where a tool sees a race that looks too narrow. And traditional tools, from sanitizers to fuzzers and static analysis, still provide signals that no model should ignore.
The reasonable future is not AI versus researchers. It is a hybrid model. AI can expand the analysis surface, suggest paths, review code, generate tests and support triage. Humans must validate, prioritise, understand impact, exploit safely in controlled conditions, fix correctly and decide what level of risk is acceptable.
Bad Epoll does not invalidate Mythos or Project Glasswing. It grounds them. AI is already a necessary tool in vulnerability research, but it is still not sufficient. That may be the most important lesson for defensive security teams: human judgement has not become obsolete. It has become more valuable because it now has to govern a new generation of powerful, but fallible, tools.
Frequently asked questions
What is Bad Epoll?
Bad Epoll is a Linux kernel vulnerability, tracked as CVE-2026-46242, affecting the epoll subsystem. It combines a race condition with a use-after-free.
What can the vulnerability allow?
Under certain conditions, it can allow a local unprivileged process to escalate privileges to root. The researcher also points to potential Android impact, although the full Android exploit was still in development.
Which versions may be affected?
The bug was introduced in 2023 and may affect kernels based on version 6.4 or later if they have not received the patch or a distribution backport.
Why does it matter that Mythos missed it?
Because it shows that even advanced AI models can miss real vulnerabilities in critical code, especially when concurrency, tiny race windows and weak runtime evidence are involved.
What is the recommended mitigation?
Apply the upstream patch or the security updates provided by your Linux distribution. epoll is not a feature that can be easily disabled without affecting normal system operation.