Bad epoll (CVE-2026-46242) Local Root Exploit: Kernel Update for CloudLinux

In early July 2026, researcher Jaeyoung Chung (CompSec Lab, Seoul National University) published a proof-of-concept for Bad epoll, a use-after-free bug in the Linux kernel’s epoll subsystem. On CloudLinux 9 and 10 it lets an unprivileged local user escalate to root. On a shared host, that turns a single compromised website into root on the whole server.

The public exploit reports high reliability (99% on a 6.12 kernel), and it needs no special privileges or configuration to run.

Why this matters on a shared host

On CloudLinux 9 and 10, Bad epoll is the difference between one hacked website and a compromised server. A kernel local privilege escalation turns any code running on the server into root, and “local” here does not mean an insider or a customer you trust. It means any process on the machine, including the PHP-FPM worker behind a compromised WordPress plugin, an outdated CMS, or a site running on leaked credentials. The attacker is whoever hacked one of the sites you host.

On an unpatched host the chain is short, and none of it needs special access:

1. A web-tier compromise. An attacker exploits a vulnerable WordPress plugin, an outdated CMS, or one of the everyday web-application flaws shared hosting sees constantly. They now run as the site’s PHP-FPM or Apache identity, or its CageFS account, in theory confined to that one site.
2. Bad epoll. From that unprivileged process, the attacker uses the epoll use-after-free to become root. No prior root, no special capability, no admin action.
3. Root on the host. They now run outside every CageFS boundary and every per-tenant limit. Every other tenant’s files, databases, credentials, and backups on that server are within reach, and recovery means rebuilding the whole server.

On a patched host, or one running a KernelCare livepatch, step 2 fails: a web-tier compromise stays a web-tier compromise, one site to clean up rather than a whole server to rebuild. That is what the kernel update buys you.

If a CloudLinux 9 or 10 server in your fleet has not taken the fix and is not on KernelCare, the gap between “a customer’s site got hacked” and “the whole server is owned” is this one kernel bug.

Technical details of the bug

Bad epoll is a race condition in the kernel’s epoll event-notification subsystem. Two of epoll’s close paths run at the same time and collide: one path frees an object while the other is still writing into it, in ep_remove(). That is the use-after-free. It gives an 8-byte write into freed kernel memory, which the public exploit builds into arbitrary kernel memory access and a root shell.

Because epoll is a core kernel facility used by almost every process, the bug needs nothing unusual to reach. Any local unprivileged account can trigger it: a shell user, a cron job, or a web process that an attacker has already compromised.

A public proof-of-concept is available. Details: public PoC (J-jaeyoung/bad-epoll) · Red Hat CVE-2026-46242 · upstream fix (commit a6dc643c6931) · NVD entry for CVE-2026-46242

Affected CloudLinux versions

Legend: ✅ not affected · ❌ affected.

^† CloudLinux 9 LTS runs the TuxCare ELS kernel-lts package, which is pinned to the AlmaLinux 9.2 kernel line (5.14.0-284). The change that introduced Bad epoll was backported into the Red Hat 9 kernel after the 9.2 release, so this kernel does not contain the bug; Red Hat lists RHEL 9.0 and 9.2 as not affected. This advisory listed CloudLinux 9 LTS as affected until August 25, 2026, pending confirmation from our kernel team.

Is there a mitigation?

No. Unlike a loadable-module vulnerability, there is no workaround short of the kernel update. epoll is a core kernel facility and cannot be disabled, and per-tenant sandboxing such as CageFS does not block it, because every process uses epoll. The only fix is the patched kernel or a KernelCare livepatch. Apply Stream 1 or Stream 3 below for your platform.

Update instructions

Two delivery streams cover the affected platforms, CloudLinux 9 and CloudLinux 10: the AlmaLinux kernel (Stream 1) and the KernelCare livepatch (Stream 3). Stream 2 covered CloudLinux 9 LTS, which has since been confirmed not affected, and is kept for the record.

Stream 1: AlmaLinux kernel (CL9, CL10)

To install from the AlmaLinux testing repository now, enable it by installing the release-testing package directly from the AlmaLinux repo, update the kernel, then disable the testing repo again.

For CL10:

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-2.el10.x86_64.rpm
dnf update 'kernel*'
reboot
dnf config-manager --disable almalinux-testing

For CL9:

rpm -Uvh --nodeps https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-2.el9.noarch.rpm
dnf update 'kernel*'
reboot
dnf config-manager --disable almalinux-testing

Once the kernels reach the production repositories, a plain dnf update kernel; reboot is sufficient.

Stream 2: TuxCare ELS LTS kernel (CL9 LTS)

This stream is retained for the record only. There is nothing to install.

Stream 3: KernelCare livepatch (all affected versions)

Once available, deploy from the testing feed:

kcarectl --update --prefix test

Once promoted to the main feed, subscribed servers update automatically, or on demand:

kcarectl --update

How to verify you are patched

Stream 1 (kernel update). After updating and rebooting, compare your running kernel against the target version in the relevant stream’s most recent status callout above:

uname -r

Stream 3 (KernelCare).

kcarectl --patch-info | grep CVE-2026-46242

References

• Public PoC: github.com/J-jaeyoung/bad-epoll
• Red Hat: CVE-2026-46242
• AlmaLinux advisory: Januscape and Bad epoll
• Related: Januscape (CVE-2026-53359), fixed by the same kernel update
• NVD entry: CVE-2026-46242