On July 3, 2026, a Linux kernel vulnerability nicknamed “Bad Epoll” became public: CVE-2026-46242, a use-after-free bug in the kernel’s eventpoll subsystem — the same epoll mechanism that powers the event loops behind Redis, Nginx, and Node.js, as explained in our companion guide, What Is epoll?.
The bug is a local privilege escalation vulnerability, rated CVSS 3.1 7.8 (High), meaning it requires an attacker to already have some low-privileged access to a machine but can then be used to gain full root/kernel-level control. It affects a specific range of mainline Linux kernel versions, and researcher reporting indicates it also reaches Android devices, since AOSP kernels descend from mainline Linux.
This article covers what’s confirmed by the official CVE record, what comes only from the discovering researcher’s own writeup (and should be read with that caveat), and what remains unverified as of publication.
What Happened
CVE-2026-46242 was assigned by kernel.org, which also serves as the source of the vulnerability’s official description and CVSS score in the NVD record. According to that record, the flaw is a use-after-free vulnerability in the kernel’s eventpoll subsystem, occurring in the ep_remove() function: it clears file->f_ep while still using the file pointer inside a critical section, creating a window where a concurrent __fput() (file-release) operation can observe a transient cleared state and free the underlying object prematurely. The result is a kmem_cache_free() call operating against the wrong slab cache — the kind of memory-corruption primitive that security researchers can, with enough control over kernel memory layout, escalate into arbitrary read/write and ultimately full privilege escalation.
The vulnerability was discovered by researcher Jaeyoung Chung and reported through Google’s kernelCTF program — a bug bounty and research initiative focused on finding exploitable Linux kernel vulnerabilities under controlled conditions. Chung has published a proof-of-concept exploit and technical writeup on GitHub. Independent of the official CVE description, that writeup adds detail that should be attributed specifically to the researcher rather than treated as a kernel.org statement: it describes the exploitable race window as “about six instructions wide,” requiring precise timer-interrupt timing manipulation, and traces the root cause to a 2023 kernel commit (58c9b016e128, dated April 8, 2023) that introduced a large set of changes to the epoll code.
Per NVD and mirror trackers, the vulnerable version ranges span Linux 5.15.209 up to 5.16, 6.1.175 up to 6.2, and 6.4 up to the fixed releases — cited as 6.18.33, 7.0.10, and 7.1-rc1. Sources differ slightly on the exact upper-bound patch version number within the 6.x line, so readers should treat kernel.org’s own stable release notes as authoritative for their specific kernel branch rather than relying on a single quoted number here.
Why It Matters
epoll is not a niche corner of the kernel. It’s one of the most heavily used subsystems in Linux, sitting underneath the I/O event loops of Nginx, Redis, Node.js’s libuv, HAProxy, and effectively every high-concurrency network service that runs on Linux. A memory-safety bug in code this central and this widely exercised is significant regardless of whether it’s ultimately exploited at scale, because the affected code path runs on an enormous fraction of production Linux systems.
The practical severity, however, is bounded by the attack vector. This is a local privilege escalation (CVSS vector AV:L, requiring low-privilege access already), not a remote code execution vulnerability. An attacker needs to already be running code on the target system — as an unprivileged user, a contained process, or a compromised low-privilege service — before this bug becomes useful to them. That makes it most relevant in multi-tenant environments (shared hosting, CI runners, containers with weak isolation) and in the classic “attacker got a foothold, now wants root” stage of an intrusion, rather than as an internet-facing threat by itself.
As of publication, no evidence of in-the-wild exploitation has been found, and the vulnerability does not appear on CISA’s Known Exploited Vulnerabilities (KEV) catalog. The known working exploit code is the researcher’s own kernelCTF submission, published for research and patch-verification purposes, not an attack observed in the wild.
Industry Impact
Multi-tenant and container infrastructure carries the highest practical exposure. Any environment where multiple untrusted or semi-trusted workloads share a kernel — CI/CD runners, shared hosting, and container platforms without strong additional isolation — is the setting where a local privilege escalation like this actually matters operationally. A local-only bug is far less concerning on a single-tenant server where every process already runs with the access level of its owner.
Android’s exposure is researcher-reported, not vendor-confirmed. The discovering researcher’s writeup states that newer Android devices (citing Pixel 10, running kernel 6.6+) are affected, while older devices on pre-6.4 kernels (cited as Pixel 8) are not. No official Google or AOSP security bulletin confirming this CVE was identified as part of this article’s research. Readers and organizations managing Android fleets should treat this as a credible but unofficial claim pending a formal Android Security Bulletin entry, rather than as a confirmed vendor statement.
This is the second known epoll-area bug found in this code region in 2026. A related but distinct vulnerability, CVE-2026-43074, was patched on April 2, 2026, after being found by Anthropic’s “Mythos” model as part of its AI-assisted security research work. That earlier fix did not catch the bug behind CVE-2026-46242, which was found separately and later by a human researcher through kernelCTF. Taken together, the two disclosures are a useful data point on the current limits of AI-assisted code auditing: it can find real, serious kernel bugs, but it does not yet reliably exhaust a codebase of every related defect in a single pass.
No major distribution has published a dedicated security bulletin for this specific CVE as of this writing. Standard distro patch pipelines (which pull fixes from upstream stable kernel releases) are the expected path to remediation, but organizations should verify with their specific distribution’s security tracker rather than assume automatic coverage.
Developer Impact
Check your kernel version against the fixed releases. If you’re running a kernel in the affected ranges (5.15.209–5.16, 6.1.175–6.2, or 6.4 up to the fix), plan an update to a patched release. Because sources vary slightly on the precise 6.x cutoff version, verify the exact fixed version for your kernel branch against kernel.org’s official stable release announcements rather than a single number quoted secondhand.
This is a local privilege escalation — prioritize patching accordingly. Internet-facing services that don’t allow arbitrary code execution by untrusted parties are not directly exposed by this bug alone. Systems that do run untrusted or lower-trust code — CI runners, shared build infrastructure, multi-tenant containers, sandboxed execution environments — should treat this with higher urgency, since it’s precisely the kind of bug that turns “we got a foothold” into “we have root.”
Container and sandbox isolation matters more, not less, in light of bugs like this. A kernel-level UAF is a reminder that container isolation is not a substitute for keeping the underlying kernel patched — a privilege escalation bug in the shared kernel can, in principle, allow a compromised container to affect the host or other tenants, depending on the specific isolation boundaries in place.
Don’t treat “no known in-the-wild exploitation” as “not worth patching soon.” A working, publicly documented proof-of-concept exists. Historically, public PoC availability tends to shorten the time between disclosure and any real-world exploitation attempts, even for local-only vulnerabilities.
Business Impact
Security and platform teams running multi-tenant infrastructure should prioritize kernel patching for this CVE. Cloud providers, CI/CD platform operators, and any organization offering shared compute to less-trusted workloads are the businesses with the clearest exposure and the clearest incentive to move quickly.
Compliance teams should note the absence of a KEV listing, but not over-rely on it. CVE-2026-46242 is not currently on CISA’s Known Exploited Vulnerabilities catalog, which for many organizations is a factor in prioritization frameworks. That absence reflects “no known exploitation yet,” not “not exploitable” — a working PoC already exists, and prioritization frameworks that treat KEV-listing as the primary trigger for urgency may under-prioritize a bug like this relative to its real severity.
Organizations managing Android device fleets should track this for an official bulletin rather than acting on researcher claims alone. Given that no Google/AOSP security bulletin was found confirming this CVE as of publication, MDM and device-security teams should watch for the next Android Security Bulletin cycle rather than treating researcher-reported device impact as a confirmed, actionable advisory in isolation.
Future Outlook
Expect an eventual Android Security Bulletin entry, if the researcher-reported impact is accurate. Given the kernel version overlap with recent Android releases, it would be consistent with normal AOSP practice for this CVE to eventually appear in a monthly Android Security Bulletin, at which point the device-impact question moves from “researcher-reported” to “vendor-confirmed.”
Expect continued AI-assisted auditing of long-lived kernel subsystems. This is the second distinct vulnerability found in the same area of epoll code within roughly the same year — one via an AI model (CVE-2026-43074) and one via a human researcher working through Google’s kernelCTF program (CVE-2026-46242). Widely deployed, rarely-modified kernel code is an increasingly active target for both approaches, and neither has yet demonstrated it exhaustively finds every related bug on its own — which argues for continued layered review rather than treating either method as sufficient by itself.
Watch for whether public PoC availability shortens the window to real-world exploitation. With working exploit code already public and no KEV listing yet, this is a useful case to track for how quickly (or whether) a purely local-privilege-escalation kernel bug with a public PoC transitions into observed in-the-wild use.
FAQ
1. What is CVE-2026-46242? CVE-2026-46242, nicknamed “Bad Epoll,” is a use-after-free vulnerability in the Linux kernel’s eventpoll (epoll) subsystem, specifically in the ep_remove() function, that can be exploited for local privilege escalation. It carries a CVSS 3.1 score of 7.8 (High).
2. Who discovered Bad Epoll? Researcher Jaeyoung Chung discovered and reported it through Google’s kernelCTF program, then published a proof-of-concept exploit and technical writeup.
3. Which Linux kernel versions are affected? Per NVD and mirror CVE trackers, affected ranges span roughly 5.15.209 to 5.16, 6.1.175 to 6.2, and 6.4 up to the fixed releases. Exact upper-bound version numbers vary slightly between sources, so check your specific kernel branch’s official stable release notes for the precise fixed version.
4. Is this a remote or local vulnerability? It’s a local privilege escalation only (CVSS vector AV:L). An attacker needs existing low-privilege access to the system before this bug becomes exploitable — it is not a remote attack vector.
5. Does this affect Android? The discovering researcher’s writeup reports that newer Android devices (kernel 6.6+, cited as Pixel 10) are affected, while older devices on pre-6.4 kernels (cited as Pixel 8) are not. No official Google or AOSP security bulletin confirming this CVE was found as of publication — this should be treated as researcher-reported pending vendor confirmation.
6. Has this been exploited in the wild? No evidence of in-the-wild exploitation was found as of publication, and the CVE does not appear on CISA’s Known Exploited Vulnerabilities (KEV) catalog. A working proof-of-concept exists publicly, published by the discovering researcher.
7. Is Bad Epoll related to the earlier CVE-2026-43074? They’re in the same general area of epoll code but are distinct vulnerabilities. CVE-2026-43074 was found by Anthropic’s “Mythos” AI model and patched April 2, 2026. It did not catch the separate bug that became CVE-2026-46242, which was found later by a human researcher.
8. What should I do if I run affected infrastructure? Update to a patched kernel version as soon as practical, verified against your distribution’s official security tracker. Prioritize systems that run untrusted or lower-trust workloads — multi-tenant hosts, CI runners, and containers — since this is a local privilege escalation bug.
9. Why does the exact fixed kernel version differ between sources? NVD and secondary CVE aggregators (such as OpenCVE) show minor discrepancies in the exact 6.x upper-bound version number, likely due to how each source parses and mirrors the kernel.org record. Treat kernel.org’s own stable release announcements as the authoritative reference for your kernel branch.
10. Does this mean epoll itself is a bad design? No. This is a specific implementation bug in the reference-counting and cleanup logic within ep_remove(), not a flaw in the epoll API’s design. epoll remains a well-established, heavily used mechanism — see our companion guide, What Is epoll?, for how the underlying mechanism works.
Analyst Perspective
The most useful lens on Bad Epoll isn’t the exploit mechanics — use-after-free bugs in C are an expected category of defect, and the kernel has patched plenty of them. What’s more interesting is what this disclosure, taken together with the earlier AI-discovered CVE-2026-43074 in the same code area, actually demonstrates about the current state of vulnerability discovery.
An AI model found a real, exploitable bug in this exact subsystem earlier in 2026. A human researcher, working independently through a structured bug bounty program, found a different real, exploitable bug in the same subsystem a few months later. Neither approach caught both bugs. That’s a meaningful data point against the narrative — common in both directions — that AI auditing either “solves” security review or is purely hype. What it actually looks like in practice is complementary: different methods surface different classes of defects, and neither one is currently a complete substitute for the other.
The second, more practical implication is for how organizations should weight “local privilege escalation, no known exploitation, not on KEV” bugs in their patching queue. It’s easy to under-prioritize a bug with that profile relative to a remotely-exploitable, actively-exploited one. But a public, working PoC against a subsystem this widely deployed is exactly the kind of vulnerability that tends to get incorporated into post-exploitation toolkits once an attacker already has a foothold — the KEV catalog reflects known exploitation, which lags real-world risk by definition, not a comprehensive measure of current threat.
For teams running multi-tenant or CI infrastructure specifically, the practical takeaway is straightforward: this is a real, credible reason to move kernel patching up the queue, independent of whether it’s making headlines as an actively exploited zero-day.
Key Takeaways
- CVE-2026-46242 (“Bad Epoll”) is a use-after-free vulnerability in the Linux kernel’s eventpoll subsystem, in the
ep_remove()function, rated CVSS 7.8 (High) - It’s a local privilege escalation only — not remotely exploitable — making multi-tenant, CI, and container environments the highest-priority systems to patch
- Discovered by researcher Jaeyoung Chung via Google’s kernelCTF program, with a public proof-of-concept already available
- Affects a range of Linux kernel versions from roughly 5.15.209 through 6.x branches, up to specific fixed releases — verify exact numbers against your distribution’s official tracker
- Android impact (reported to affect kernel 6.6+ devices) comes from the researcher’s own writeup, not an official Google/AOSP security bulletin, as of publication
- No known in-the-wild exploitation and not on CISA’s KEV catalog as of publication — but a public PoC exists, which historically shortens the path to real-world exploitation attempts
- This is the second distinct vulnerability found in this area of epoll code in 2026, following an earlier AI-discovered bug (CVE-2026-43074) — a useful signal that AI and human security research are currently complementary, not redundant
Continue Learning
- What Is epoll? The Linux I/O Event Notification Mechanism Explained
- Squidbleed (CVE-2026-47729): What Developers Need to Know About the 29-Year-Old Squid Proxy Vulnerability
- libssh2 CVE-2026-55200: Remote Code Execution Explained
- AI-Accelerated Cyberattacks: How AI Is Shrinking the Defender’s Response Window
- Insecure Deserialization Explained
About GAVIHOS
GAVIHOS helps developers, founders and technology enthusiasts understand AI, software engineering and emerging technologies through practical guides, tutorials and industry analysis.
Stay Updated
Follow GAVIHOS for practical AI, technology and developer-focused insights.
EXTERNAL LINKS
| Source | URL |
|---|---|
| NVD — CVE-2026-46242 | https://nvd.nist.gov/vuln/detail/CVE-2026-46242 |
| OpenCVE — CVE-2026-46242 | https://app.opencve.io/cve/CVE-2026-46242 |
| CISA Known Exploited Vulnerabilities Catalog | https://www.cisa.gov/known-exploited-vulnerabilities-catalog |