Bad Epoll (CVE-2026-46242)

Bad Epoll is a race-condition use-after-free vulnerability in the Linux kernel's epoll subsystem, tracked as CVE-2026-46242. epoll is the kernel's event notification and I/O multiplexing mechanism — the interface a server process uses to say "watch these ten thousand connections and wake me when one of them has data." The bug sits in how epoll cleans up after itself: when two of epoll's close paths run concurrently, one path can free an object while the other is still writing to it.

A write into freed kernel memory sounds small. It isn't. The public analysis shows how that narrow use-after-free write is turned into control of a file object, then into arbitrary kernel memory access, and finally into kernel code execution — a reliable local privilege escalation from an unprivileged user account to root.

The bug was reported and exploited by security researcher Jaeyoung Chung as a 0-day submission to Google kernelCTF — Google's programme that pays $71,337 and up for working Linux kernel exploits, precisely so that bugs like this are found and fixed rather than sold. A public exploit and technical analysis exist in the GitHub repository bad-epoll, which means the exploitation technique is documented and reproducible, not theoretical.

Linux kernels 5.10 through 6.11 are confirmed affected — a range that covers the kernels shipped by essentially every mainstream server distribution of the past several years. Exploitation requires local access: an attacker must already have shell-level code execution on the machine. That qualifier matters, and we'll come back to why it offers less comfort than it sounds like it should.

Most kernel CVEs live in subsystems a typical web server never touches — an obscure filesystem, a niche network protocol, a driver for hardware you don't own. Bad Epoll is the opposite. epoll is how modern server software scales, and essentially all high-performance server software uses it: nginx and Apache use it to juggle thousands of simultaneous HTTP connections; Node.js is built on an event loop that rests on epoll; PHP-FPM's master process world depends on it; Python's asyncio uses it; the databases behind your application use it.

On a Magento hosting box, that means the vulnerable code isn't merely present in the kernel — it is loaded, exercised constantly, and reachable from any process on the machine. nginx accepting checkout traffic, PHP-FPM executing Magento's PHP, the database serving catalogue queries: all of it stands on epoll. There is no realistic configuration of a Magento server that avoids the affected subsystem, because the subsystem is the machinery the whole stack runs on.

That's what makes Bad Epoll worth your attention even if you never read kernel advisories. When the flaw is in a component this universal, "does this affect my server?" has a short answer: if the kernel version is in range, yes.

Bad Epoll is local-only: it cannot be fired at your store from the internet. But "local-only" does not mean "low risk" for an ecommerce server — it means "the second step of a two-step attack." Magento supplies the first step far too often. A vulnerable third-party extension, an unpatched core CVE, or a compromised admin account gives an attacker a webshell running as the web server user — typically www-data or nginx. That webshell is exactly the shell-level local access Bad Epoll requires.

Ordinarily, a webshell is a contained problem: the attacker is boxed in by the web user's limited permissions. Chain it with an unpatched Bad Epoll and the box disappears. From root, an attacker can read every customer record and order, inject card skimmers directly into your checkout, install rootkits that survive reboots and malware scans, and tamper with the logs that would have told you any of it happened. Our Magento Security Centre covers the web-layer half of that chain in detail — the extension audits, admin hardening and patching discipline that stop attackers from getting the foothold in the first place.

The picture is worse on shared hosting. On a shared or multi-tenant platform, every tenant's processes share one kernel. If any tenant on the box — not you, someone else, a site you've never heard of — gets compromised at the web layer, Bad Epoll turns their foothold into root on the machine you both live on. One tenant's root is every tenant's exposure. We covered the same dynamic in our advisory on GhostLock (CVE-2026-43499), and it applies here without modification: on shared infrastructure, your security is bounded by the least secure site on the server.

Bad Epoll is one of three Linux root flaws patched in the same fortnight — alongside GhostLock and Januscape (CVE-2026-53359), a KVM escape affecting virtualised infrastructure. Three unrelated bugs in three different subsystems, one shared conclusion: your host's kernel patch cadence is not a back-office detail. It is a core part of your store's security posture.

Bad Epoll also affects Android. Android is built on the Linux kernel, and epoll underpins Android's event-loop infrastructure — the machinery apps and system services use to wait on events. The same race condition in epoll's close paths is therefore present on Android devices running affected kernels.

For server owners, the Android angle is mostly a signal of scale. A single bug that reaches both the phone in your pocket and the nginx process serving your checkout is a bug in genuinely foundational code. Subsystems that widespread attract attackers and researchers alike — which is exactly why programmes like Google kernelCTF pay serious money to get these bugs disclosed and fixed first.

SSH into your server and run:

uname -r

Kernels 5.10 through 6.11 are affected unless your distribution has backported the fix — so the version number alone doesn't clear you; you need to check it against your distribution's advisory for CVE-2026-46242:

• Ubuntu: check Ubuntu Security Notices (USN) for CVE-2026-46242
• Debian: check the Debian Security Tracker entry for CVE-2026-46242
• RHEL / Rocky: check the Red Hat CVE database for CVE-2026-46242
• AlmaLinux: patched kernels for AlmaLinux 9 and 10 reached production repositories on 6 July 2026 (the same release that fixed Januscape)
• CloudLinux: updates have shipped — confirm your kernel matches the fixed version in the CloudLinux advisory

If your running kernel predates the fixed version for your distribution, update via your package manager (apt, yum, dnf) and reboot the server.

EveryHost servers receive kernel patches as part of standard managed Magento 2 hosting. The patched kernels released on 6 July 2026 are being applied across the Magento hosting fleet as part of our normal patch process — no customer action required.

We are not claiming our Sentinel WAF blocks Bad Epoll. It doesn't — no WAF can mitigate a kernel bug, and any provider who tells you otherwise is selling comfort rather than security. What Sentinel does is block the web-layer half of the chain: the Magento extension exploits, webshell uploads, and admin brute-force attacks an attacker needs to establish the local foothold before a kernel bug like Bad Epoll becomes usable at all.

Architecture does the rest. EveryHost runs single-tenant dedicated Magento hosting — your server, your kernel, no other tenants. A kernel-level event on a single-tenant server is bounded to one customer's site and one customer's reboot window, not a shared node full of strangers. That doesn't make kernel patching optional — we patch — but it means the blast radius of the next epoll-class bug, whenever it arrives, is already contained by design.