Skip to content
feed: live
>_ 0dayNews
linux kernel

GhostLock: 15-Year Linux Kernel Root/Container Escape

Nebula Security's GhostLock (CVE-2026-43499) — a 15-year-old futex use-after-free — hits every mainstream Linux distro. Escapes containers. Patch again.

Marisol "Fuse" Delgado · Published · 4 min read

If you run Linux anywhere that matters — and if you’re reading this, you do — a new kernel local-privilege-escalation named GhostLock (CVE-2026-43499) went public today and it’s the kind you patch this week, not next quarter. Nebula Security disclosed it. The affected code has been in the kernel since 2011. Every mainstream distribution has shipped it by default the entire time. Local user, no special permissions, no network access, root in about five seconds. Nebula’s exploit was 97% reliable in their own testing. And yes, it escapes containers.

The upstream patch landed in April. That is not the honest timeline for you.

What changed

GhostLock is a use-after-free in the kernel’s futex priority-inheritance code path — the lock-fairness plumbing threaded programs lean on. Ordinary threading calls from any local program are enough to reach it. That is as much mechanics as we’re publishing; if you want depth, Nebula’s own writeup at nebusec.ai and the NVD record have it, along with their kernelCTF submission. Google paid Nebula $92,337 through kernelCTF for the disclosure.

Nebula chained this with a Firefox renderer bug (CVE-2026-10702) into a browser-to-root chain they call IonStack. That is worth flagging separately: sandbox-out plus GhostLock is a drive-by-to-root story on any unpatched Linux desktop with Firefox in front of it. On a server fleet it’s the second half of intrusion chains — foothold plus GhostLock is how “compromised web-app account” becomes “compromised host and every other tenant on it.” Same shape as Bad Epoll (CVE-2026-46242) from last week, only with 15 years’ worth of running fleets in scope this time instead of just 6.4+.

CISA has not added GhostLock to KEV. Nebula’s exploit is public. Assume that gap closes.

The April fix is not enough

The upstream commit that fixed GhostLock in April introduced a separate crash bug now tracked as CVE-2026-53166. If your fleet is on a distro release that pulled the first patch and nothing since, you’re exposed to a stability regression on top of the memory-corruption bug you were trying to close. Distros will roll both fixes forward on their normal security-advisory feeds; the practical rule is you want the most recent point release of your kernel series, not the first one that “fixed GhostLock.” Confirm the running kernel with uname -r and check that against your distro’s advisories for CVE-2026-43499 AND CVE-2026-53166 before you call a host done.

What to actually do

Patch order, servers:

  • Shared and multi-tenant hosts first. Anything where users you don’t control can log in and run code — build farms, CI runners, HPC clusters, jump boxes, container hosts running untrusted workloads. Kernel local privesc plus shared tenancy is the fastest path from “one compromised account” to “compromised environment.”
  • Container hosts and Kubernetes nodes second. Container isolation does not stop a kernel bug. The container’s kernel is the host’s kernel. If you have a “workloads are isolated” story that leans on that assumption, GhostLock breaks it — patch the node.
  • Cloud VMs third. Single-tenant cloud instances still take this on your normal cadence, but you’re less likely to have unknown local users than in the two categories above.
  • Workstations and admin laptops fourth. Ship the update on the next reboot window. The Firefox chain gives this real teeth on desktops.

Distributions:

Track your distro’s security feed for CVE-2026-43499. Ubuntu 24.04 / 22.04 / 20.04 LTS, Debian, Fedora, Rocky, SUSE, and Arch will land backports on their normal cadence. Do not roll your own kernel from mainline over this unless you already do that as policy — you’ll trip over the follow-up fix.

What you can do today, before the distro patch lands:

  • Keep untrusted users off affected hosts. Local privesc requires local code execution; anything that keeps random shell users off the box also stalls GhostLock. This is not a fix.
  • Nebula lists RANDOMIZE_KSTACK_OFFSET and STATIC_USERMODE_HELPER as kernel build options that make their exploit harder. These are hardening knobs, not workarounds — if you already have a distro kernel with them on, good; if you don’t, don’t rebuild your kernel over this. Wait for the patch.
  • Android is not directly in the GhostLock scope Nebula published, but a related futex flaw (Bad Epoll) already reaches Android device kernels. Watch OEM patch levels.

Priority call

Patch this. This week if you can, next patch window if you can’t. It ranks with — not above — the pre-auth RCE stories on the CISA KEV feed today; GhostLock does need local access, and that’s not nothing. But you have a public working exploit, a 15-year install base, container escape confirmed, and a first-round fix that broke stability. The window between “everyone knows” and “someone weaponizes this into an intrusion kit” is measured in weeks, not months.

If you patched Bad Epoll on the normal cadence, this is the same drill with a wider blast radius. Do it again.

Sourcing

Found this useful? Share it.