A working proof-of-concept for CVE-2026-43499, nicknamed GhostLock, went public on July 7, 2026. It hands any unprivileged local user a root shell in about five seconds, and it works from inside a container to escape to the host. If you run Linux servers — shared hosting, VPS, or bare metal — this is the one to patch before anything else this week.

What GhostLock is

The bug lives in kernel/locking/rtmutex.c, on the futex priority-inheritance (PI) path. When the kernel handles a FUTEX_CMP_REQUEUE_PI requeue and detects a deadlock cycle, it rolls back with -EDEADLK by calling remove_waiter(). The problem: that helper clears pi_blocked_on on the wrong thread — not the sleeping thread it should be cleaning up, but the currently running task. That leaves a live thread holding a dangling pointer into already-freed kernel stack memory. Stack use-after-free.

An attacker constructs a specific deadlock pattern with three futexes and coordinated threads, reclaims the freed frame with a forged waiter structure, and chains that into arbitrary kernel read/write and finally root. The research team at Nebula Security, who discovered it with their automated analysis tool VEGA, reports the exploit achieves root about 97% of the time in roughly five seconds. CVSS 7.8 (High). No special capabilities or prior access required.

The flaw was introduced in Linux 2.6.39, which puts it squarely in 2011. Fifteen years of quiet presence across essentially every major distribution, because CONFIG_FUTEX_PI — the only prerequisite — is enabled by default everywhere. It is the kind of race condition that tends to slip past traditional fuzz testing but surfaces quickly under more directed analysis. Red Hat has published RHSB-2026-010.

Why shared hosting and containers are especially exposed

For shared hosting, the arithmetic is blunt: any customer with shell access can run this exploit and become root. That covers customers running cron jobs, SSH sessions, or applications with an interactive terminal. There is no practical way to restrict access to the FUTEX_CMP_REQUEUE_PI syscall without breaking POSIX thread semantics in glibc, so syscall filtering is not a realistic mitigation. You patch, or you are exposed.

For container environments, the situation is equally uncomfortable. The exploit works across the namespace boundary — an attacker inside a Docker or LXC container can escape to the host. Container isolation is enforced in the kernel. When there is a kernel-level LPE, namespaces and cgroup boundaries do not help.

Patch status across distributions

The mainline fix landed in Linux 7.1 (commit 3bfdc63936dd). Distributions have been shipping backported patches since July 7–9. The AlmaLinux blog has the most detailed public write-up; patches are now available in the standard production repos:

  • AlmaLinux 8: kernel-4.18.0-553.141.2.el8_10 or higher
  • AlmaLinux 9: kernel-5.14.0-687.24.1.el9_8 or higher
  • AlmaLinux 10: kernel-6.12.0-211.32.1.el10_2 or higher
  • CloudLinux: patches available — see the CloudLinux blog
  • RHEL / Rocky / Oracle Linux: kpatch updates and full kernel updates rolling out via RHSB-2026-010
  • Debian / Ubuntu: updates available through the normal security channels

What to do right now

Install the kernel update and reboot. There is no runtime workaround.

# AlmaLinux / RHEL-based
sudo dnf clean metadata && sudo dnf upgrade && sudo reboot

# Debian/Ubuntu
sudo apt update && sudo apt upgrade && sudo reboot

After rebooting, confirm with uname -r that you are running the patched version. Live-patching tools like TuxCare KernelCare can apply this without a reboot, but you still need to confirm the patch is active.

What this means for kalfaoglu.net customers

Servers we manage received kernel updates starting July 9, within our standard maintenance window, and the reboot cycle is complete. No customer data was accessed through this vulnerability on our infrastructure.

If you manage your own VPS kernel — that is, you opted out of managed updates — run uname -r and compare it against the patched versions listed above. If you are behind, open a support ticket and we will coordinate the update and reboot around a window that works for you.

One broader note: GhostLock is a useful reminder that container security boundaries are enforced in the kernel. When the kernel itself has an exploitable LPE, those boundaries disappear. If you run sensitive workloads in containers on shared infrastructure, this is a reasonable moment to review whether AppArmor profiles, seccomp filters, or dedicated VMs belong in your setup.