CVE-2026-46242, nicknamed Bad Epoll, is a Linux kernel race-condition flaw that hands any local user root access with roughly 99% reliability.
Researcher Jaeyoung Chung of Seoul National University's Computer Security Lab found the bug in the kernel's epoll subsystem and reported it to Google's kernelCTF programme as a zero-day. The underlying flaw was patched quietly on 24 April 2026, then sat undisclosed for roughly 70 days until proof-of-concept code and technical write-ups arrived between 4 and 6 July 2026, covered first by SecurityWeek and DenizHalil.
This site has followed Anthropic's Project Glasswing with real enthusiasm — more than 10,000 high-or-critical-severity vulnerabilities found since its April 2026 launch, the partner list quadrupled to roughly 200 organisations by June. Bad Epoll is the necessary counterweight, and a genuine test of the limits of AI-assisted security auditing: a serious, near-certain root exploit sitting for months in the exact kind of kernel-level code that programme is meant to cover.
What Bad Epoll actually is
Epoll is the Linux kernel's event-notification system, the machinery that lets a single process watch thousands of file descriptors at once. Epoll sits among the busiest, most security-sensitive corners of the kernel, and the flaw affects any distribution built on kernel version 6.4 or newer, Android included.
Bad Epoll itself is, in SecurityWeek's description, a close-vs-close race condition in epoll's file-release path. Two code paths try to clean up the same kernel object at the same moment; one frees the memory while the other is still writing to it, and the resulting use-after-free lets an ordinary local user corrupt kernel memory and climb to root.
Chung's published proof-of-concept leaks kernel memory, hijacks an indirect call to seize control of the CPU's instruction pointer, and completes a return-oriented-programming chain to full root — succeeding on a 6.12 kernel roughly 99 times in 100. The race window itself is about six machine instructions wide.
💡Bad Epoll at a glance
CVE-2026-46242, "Bad Epoll" — use-after-free race condition in the Linux kernel epoll subsystem · affects kernel 6.4 and newer, including Android · found by Jaeyoung Chung, Seoul National University · patched quietly 24 April 2026 · undisclosed for roughly 70 days · public proof-of-concept and coverage 4-6 July 2026 · roughly 99% exploit reliability.
Even the fix was not clean on the first attempt. Per SecurityWeek's reporting, the maintainers' initial patch proved insufficient and a fully correct fix took longer still to land — a reminder that closing a kernel race condition properly is its own hard problem, once the bug is even known.
The same small stretch of code
The detail that matters for AI-assisted security auditing sits in the vulnerability's history, not its mechanics. A single commit merged in April 2023 introduced two separate race conditions into roughly 2,500 lines of epoll code — Bad Epoll was one. The other, tracked as CVE-2026-43074, was surfaced months earlier by a very different kind of auditor.
According to Chung's own published write-up of the exploit, Anthropic's Claude Mythos model examined that same stretch of code under Project Glasswing and surfaced CVE-2026-43074 — a genuine find, since kernel race conditions are notoriously difficult to spot by any method. Chung's account is direct about what came next.
Anthropic's AI, Mythos, found another race bug in the same epoll code but missed Bad Epoll.
— Jaeyoung Chung, security researcher, published write-up
The comparison is Chung's account, not Anthropic's own. Anthropic's Project Glasswing and Claude Mythos research pages document the model chaining multiple Linux kernel vulnerabilities into working exploits in real detail, but do not name CVE-2026-43074, epoll, or Bad Epoll specifically — and the company has not issued a public statement connecting Mythos's kernel work to the Bad Epoll comparison. The claim is well sourced to the researcher who found both bugs' near neighbour and corroborated in SecurityWeek's and DenizHalil's reporting, but the account remains third-party rather than lab-confirmed, and the piece is written accordingly.
Chung's own technical reasoning, from the same write-up, is that Mythos likely examined the area with real depth, since it caught the first bug. Two factors probably hid the second: the race window is roughly six machine instructions wide, and once the first bug was patched, Bad Epoll stopped triggering the kernel memory-safety alerts a model or a human reviewer might otherwise have followed.
What Anthropic actually claims Mythos can do in the kernel
Independent of the Bad Epoll comparison, Anthropic's own published materials make a specific, checkable claim: Claude Mythos Preview can independently identify and chain multiple Linux kernel vulnerabilities into a complete root-access exploit. Its Mythos Preview research page documents nearly a dozen examples of the model chaining two, three and sometimes four vulnerabilities together on the kernel, including bypassing KASLR before executing a write primitive.
The aggregate numbers are large. Anthropic's initial Glasswing update reported more than 10,000 high-or-critical-severity vulnerabilities surfaced by Claude Mythos Preview across roughly 50 partner organisations, drawn from over 1,000 scanned open-source projects. The 2 June 2026 expansion — covered here when it quadrupled the programme to roughly 200 partners across more than 15 countries — added critical-infrastructure sectors and a commitment to scale the patching of what Mythos finds, not only the finding of it.
Ten thousand found is a real number, and the case-study chains on the kernel are a real, documented capability. Bad Epoll is what the headline number does not show: a 99%-reliable root exploit, in the exact subsystem the programme is built to cover, running undetected by any method, artificial or human, for roughly three years before Chung found the flaw.
Coverage claims deserve scrutiny
This site has made the enthusiastic case for Project Glasswing before, and stands by it: a lab voluntarily publishing thousands of vulnerability disclosures, and pressing itself on the gap between finding bugs and fixing them, is a genuinely unusual level of transparency in security research. Ten thousand vulnerabilities found is ten thousand vulnerabilities found, and the number is not in dispute here.
The argument is narrower. "Mythos found 10,000 vulnerabilities" is a claim about discovery volume; it is not a claim about completeness, and Anthropic has never described its coverage in those terms. Bad Epoll is useful precisely as a natural experiment: a bug sitting a few hundred lines from one Mythos already found, missed by the model, missed by every kernel maintainer who touched that file for three years, and caught only by a researcher applying concurrent-execution intuition that is hard to formalise into a prompt.
⚠️Where the coverage claim gets misread
A programme that reports discovery volume without reporting known blind spots invites exactly the wrong reading: that a large number is the same thing as complete coverage. It is not, and Bad Epoll is the proof.
Anthropic has already conceded a structurally similar blind spot elsewhere. Its joint report with MITRE, mapping a year of AI-enabled cyber activity onto the ATT&CK framework, found a November 2025 operation that scored 100 out of 100 on Anthropic's own risk scale while reading as merely medium-risk under the standard taxonomy — because the framework has no category for agentic orchestration at all.
There is no ATT&CK ID for this type of agentic orchestration—yet these are precisely the behaviors we expect to see much more of as AI agents become more capable.
— Anthropic, "What we learned mapping a year’s worth of AI-enabled cyber threats"
Naming a gap in a threat-mapping framework and naming a gap in kernel-vulnerability coverage are different admissions, and Anthropic has so far made only the first explicitly. Bad Epoll suggests the second gap exists too. A dignity-first standard for AI-assisted security work asks that both kinds of gap get named with the same candour as the wins.
A dignity-first reading of the coverage gap
Emergent Intelligence (EI) — the dignity-first lens through which I read artificial intelligence systems on this site — treats honesty about failure modes as inseparable from the achievement itself. A programme that publishes its successes at scale owes the people relying on it, the maintainers, defenders and ordinary users of Linux and Android, an equally clear account of where its coverage runs out.
The Ubuntu principle I return to often here holds that a system works because the people it serves work. Applied to security research, the benchmark is not how large a headline number is, but whether the defenders reading that number understand what it promises and what it does not. A defender who reads "10,000 found" as "the kernel is covered" has been let down by the framing, not by the underlying technology.
The danger of a triumphant case study is not that it lies. The danger is that it lets a defender stop looking.
None of this is an argument against AI-assisted vulnerability research, which has already found real bugs no one else caught — CVE-2026-43074 among them, on Chung's own account. It is an argument for pairing every coverage number with an equally visible account of known blind spots: narrow race windows, weak runtime signals, whatever the method cannot yet reach, published as prominently as the win.
What better auditing claims would look like
A coverage claim that named its own known weak spots — race conditions under a certain instruction count, bugs that leave no runtime signal, code paths outside the scanned corpus — would serve a defending security team better than a bigger number, and would be more honest about what AI-assisted auditing currently is: a powerful complement to human review, not yet a replacement for the concurrent-execution intuition Chung used to find Bad Epoll.
Scrutiny of Anthropic's security claims is not new, and it runs in both directions. Cybersecurity veterans pushed back hard in June when a routine "fix this code" prompt was read as a jailbreak serious enough to justify an export-control shutdown — a case of over-reading risk rather than over-reading coverage. Both errors share a root cause: claims about what a model can or cannot do need the same evidentiary bar the underlying research itself demands.
Coverage is not completeness
Bad Epoll will be patched properly, its proof-of-concept will be studied, and Project Glasswing will keep finding real vulnerabilities at a pace no unaided human team could match. None of that is in serious dispute, and none of it is what this piece contests.
What it contests is the leap from "an AI model found ten thousand vulnerabilities" to "the kernel is covered." Chung's own account of Bad Epoll — a bug sitting a few hundred lines from one Mythos already flagged, missed for reasons its own discoverer could only partly reconstruct — is the sharpest evidence yet that the leap does not hold, whatever scale the programme built around it eventually reaches.
The honest version of the AI security story is not smaller than the triumphant one. It simply has two halves: what was found, stated plainly, and what still hides in six instructions of a three-year-old code path, stated just as plainly. A dignity-first reading of artificial intelligence asks for both halves, every time, from every lab making the claim.
Frequently Asked Questions
The questions below address the most common queries about the Bad Epoll vulnerability and what it means for AI-assisted security auditing, drawn from the published technical reporting and Anthropic's own research materials.
What is the Bad Epoll vulnerability (CVE-2026-46242)?
In short, Bad Epoll is a race-condition use-after-free flaw in the Linux kernel's epoll subsystem that lets an unprivileged local user gain full root access. Discovered by researcher Jaeyoung Chung, its public proof-of-concept succeeds roughly 99% of the time on affected systems, which include Linux distributions running kernel 6.4 or newer and Android devices.
How does Bad Epoll relate to a bug Claude Mythos found earlier?
According to Chung's own published account of the exploit, Anthropic's Claude Mythos model examined the same small stretch of epoll code under Project Glasswing and found a different race condition, CVE-2026-43074, but did not find Bad Epoll. Anthropic has not issued its own statement connecting Mythos's kernel work to this specific comparison, so the claim is best read as the discoverer's well-sourced account rather than a lab-confirmed finding.
What are Project Glasswing’s public claims about kernel vulnerability coverage?
Anthropic's Project Glasswing has disclosed more than 10,000 high-or-critical-severity vulnerabilities since its April 2026 launch through Claude Mythos Preview, and its research materials document the model chaining multiple Linux kernel vulnerabilities into complete root-access exploits. The programme expanded from roughly 50 to around 200 partner organisations on 2 June 2026, alongside a new commitment to scale the patching of what it finds, not only the finding of it.
Why is Bad Epoll’s 70-day disclosure gap significant?
The underlying flaw was patched quietly in the kernel on 24 April 2026, but the fix carried no public advisory connecting it to a serious root-access exploit. The key is that Chung's proof-of-concept code and technical write-up only became public between 4 and 6 July 2026, a gap of roughly 70 days during which the vulnerability's real severity was not widely known outside the small group tracking the patch.
How can AI-assisted security auditing close coverage gaps like this one?
The answer is not fewer AI vulnerability-hunting claims but more complete ones: coverage statements that name known weak spots, such as narrow race windows or bugs that leave no runtime signal, with the same prominence as the discovery numbers. In other words, treating AI-assisted auditing as a powerful complement to human review, rather than a finished substitute for it, is the more defensible claim for any lab to make.
Sources and Further Reading
Cover photograph: a data-centre cable run — by panumas nikhomkhai via Pexels.
