High CVE-2026-46242 — Bad Epoll is a use-after-free in the Linux kernel's epoll code that lets a local user get root or break out of a container. How to check your kernel and which Proxmox, Debian, and Ubuntu versions fix it.
Published 2026-10-08 · Last updated 2026-10-08
TL;DR: Any process that can run code on a Linux 6.4+ host, including one inside an unprivileged LXC or Docker container, can race two epoll file descriptors closing and get kernel memory corruption that leads to root on the host. There is no config workaround. Install a fixed kernel and reboot into it.
| CVE | CVE-2026-46242 (“Bad Epoll”) |
|---|---|
| Component | Linux kernel, fs/eventpoll.c |
| Type | Use-after-free (race) → local privilege escalation / container escape |
| CVSS 3.1 | 7.8 High (AV:L/AC:L/PR:L/UI:N) |
| Affected | Kernel 6.4 and newer without the fix (bug present since 2023) |
| Not affected | Kernels older than 6.4, e.g. Debian 12’s stock 6.1 |
| Fixed in | Proxmox VE 8: proxmox-kernel-6.8.12-33; Proxmox 7.0 series: 7.0.14; Debian 13: 6.12.95-1 (DSA-6381-1) |
| Exploited? | Public proof-of-concept reported; not on CISA’s KEV list as of 2026-10-04 |
epoll is how almost every Linux server program (nginx, Node.js, Java, game servers, container runtimes) waits on many sockets at once. An epoll instance can watch another epoll instance. Bad Epoll is a race in the code that removes one from the other.
When a watched epoll file is closed at the same moment it is being removed, ep_remove() briefly clears a pointer and keeps using the file. A concurrent close sees the cleared pointer, takes a shortcut, and frees the object. The first path then writes into freed kernel memory. An attacker who wins that race reliably can turn it into arbitrary kernel read/write, which means root.
No special privileges are needed: creating epoll instances and closing file descriptors is something every unprivileged process can do.
Containers share the host’s kernel. Unprivileged LXC, Docker, and Podman isolate processes with namespaces and cgroups, but a kernel memory-corruption bug sits underneath all of that. Root inside the kernel is root on the host, and from there every other container on the box.
What makes this one worse than Copy Fail is that there’s no module to unload or sysctl to flip. If you run untrusted or internet-facing code in an LXC (a game server with plugins, a web app, a honeypot), that container is one bug away from the host until you patch.
KVM virtual machines are a different story. A VM runs its own guest kernel, so exploiting Bad Epoll inside a VM gets root in that VM, not on the hypervisor. Patch the guests too, but the host is the priority.
Check the kernel you are running, not just the one installed. A patched package does nothing until you reboot into it.
# Running kernel
uname -r
# Proxmox: running kernel vs installed kernels
pveversion -v | grep -E 'running kernel|proxmox-kernel'
# Proxmox: does your installed kernel series include the fix?
apt changelog proxmox-kernel-6.8 2>/dev/null | grep -m1 -B8 'CVE-2026-46242'| Platform | Vulnerable if running | Fixed |
|---|---|---|
| Proxmox VE 8 (6.8 kernel) | older than 6.8.12-33-pve | 6.8.12-33-pve (2026-07-07), improved backport in -37. Use the latest. |
| Proxmox VE 9 (7.0 kernel) | older than 7.0.14 | 7.0.14+ |
| Proxmox VE 9 (6.17 opt-in kernel) | Fix shipped after the 6.8 one. Run the apt changelog check above against proxmox-kernel-6.17. | |
| Debian 13 trixie (6.12) | older than 6.12.95-1 | 6.12.95-1 (DSA-6381-1) |
| Debian 12 bookworm (6.1) | Not affected. 6.1 predates the bug. Backport kernels (6.4+) are affected. | |
| Ubuntu, RHEL, others | Check your distro’s tracker for CVE-2026-46242. Any 6.4+ kernel built before June 2026 is suspect. | |
Proxmox VE:
apt update
apt full-upgrade # never plain "apt upgrade" on Proxmox
pveversion -v | grep proxmox-kernel
rebootAfter the reboot, confirm with uname -r. If you pinned a kernel with proxmox-boot-tool kernel pin, unpin it first or you will boot right back into the vulnerable one:
proxmox-boot-tool kernel list
proxmox-boot-tool kernel unpinDebian / Ubuntu: apt update && apt full-upgrade && reboot. If you can’t take downtime, live-patching services (Ubuntu Livepatch, KernelCare) may cover it. Check their CVE list before relying on that.
Plan the reboot. On a Proxmox host every container and VM goes down with it. Check that each guest has onboot: 1 set and that services inside start on their own, so you don’t find a dead game server the next morning.
There is no clean workaround. The bug is in core kernel code every program uses. Until you can reboot:
Failed race attempts can crash or oops the kernel. Look for epoll in kernel warnings:
journalctl -k | grep -iE 'eventpoll|ep_remove|KASAN|use-after-free|general protection'A clean log doesn’t prove much, since a successful exploit leaves no trace in it. If a container was internet-facing and unpatched, treat its host as worth a closer look: unexpected processes, new users, unfamiliar cron or systemd units.
apt changelog proxmox-kernel-6.8, entry 6.8.12-33Desert Forge IT patches, monitors, and backs up servers and networks for Phoenix-area businesses. We track advisories like this one so you don’t have to. Get a free consult and we’ll tell you what you’re exposed to.