Public Exploit Turns 15-Year Linux Kernel Flaw Into 5-Second Root Attack

A working exploit for a Linux kernel flaw that has existed since 2011 is now publicly available, and any logged-in user can run it to gain full root control of an affected machine in roughly five seconds — no special configuration, no administrator access, no network required. The vulnerability, tracked as CVE-2026-43499 and named GhostLock by the researchers who found it, also breaks out of Docker and Kubernetes containers, making cloud and shared infrastructure the highest-priority targets for patching.

Nebula Security's VEGA team disclosed GhostLock on July 7, 2026, alongside a full technical writeup and open-source proof-of-concept code. Nebula Security's writeup Google's kernelCTF bug-bounty program, which rewards researchers for demonstrated Linux kernel exploits, awarded the team $92,337 for the submission — a figure that reflects both the severity of the bug and the quality of the exploitation chain.

The flaw has been present in every mainstream Linux distribution — Ubuntu, Debian, Red Hat Enterprise Linux, Fedora, Arch, and virtually every other distribution shipping a kernel built since May 2011 — without detection for fifteen years. GhostLock was introduced with Linux kernel version 2.6.39 and remained reachable through 7.1-rc1. A patch exists upstream, but distribution packages are still rolling out, and Ubuntu's three Long-Term Support releases — 24.04, 22.04, and 20.04 — were still listed as vulnerable or in progress as of July 8, 2026.

GhostLock lives in the Linux kernel's real-time mutex subsystem, in a mechanism called priority inheritance. The mechanism exists to prevent a mundane scheduling problem: if a low-priority task holds a lock that a high-priority task needs, the high-priority task sits blocked until the lock holder finishes — a situation called priority inversion. Priority inheritance resolves this by temporarily boosting the low-priority holder's scheduling priority to match the waiter's, letting it finish and release the lock.

The bug is in a cleanup function called remove_waiter(), originally written for the straightforward case where a thread blocks on its own behalf and later cleans up after itself. On that path, current — the thread the CPU is currently executing — is always identical to the task that owns the waiter object being cleaned up. The function uses current as a shorthand and clears current->pi_blocked_on to record that the task is no longer waiting.

The problem is that remove_waiter() was later reused on a different path — the Requeue-PI proxy path — where a third thread issues a FUTEX_CMP_REQUEUE_PI system call on behalf of a sleeping waiter. On this proxy path, current is the thread issuing the requeue, not the sleeping waiter. When the kernel detects a deadlock and rolls back the requeue, remove_waiter() clears the wrong task's pi_blocked_on. The sleeping waiter returns from its system call with pi_blocked_on still pointing at a rt_mutex_waiter object that now sits on its own freed kernel stack.

That dangling pointer is the vulnerability — a use-after-free on the kernel stack . The sleeping task returns to userspace while the kernel retains a pointer to memory it has already freed and may have reallocated to an entirely different object. Any subsequent operation that walks the priority-inheritance chain through that task will dereference the stale pointer.

Nebula's team turned that primitive into a full root exploit by chaining several steps: reusing the freed stack frame via a PR_SET_MM_MAP call that plants a forged waiter structure; triggering the kernel to dereference it and overwrite a function pointer in inet6_protos[IPPROTO_UDP]; hosting a fake inet6_protocol and ROP gadgets in the CPU entry area at a known physical address; and using a one-write "DirtyMode" technique to flip permission bits on the core_pattern sysctl, completing the privilege escalation entirely in userspace. The exploit reliably reaches root in five seconds on the kernelCTF test environment. GhostLock exploit chain details

The reliability figure — 97% across common configurations — is notable. Most kernel exploits require precise memory layout information that varies between machines and kernel versions, making consistent weaponization difficult. GhostLock achieves its high success rate partly because the race window, once staged, imposes no time pressure: the dangling pointer persists indefinitely while the waiter task sits in userspace, and the attacker can trigger the chain walk at any convenient moment. Nebula reports the exploit likely works on single-core CPUs as well.

GhostLock carries a CVSS score of 7.8 out of 10, placing it in the "High" severity tier rather than "Critical." That score reflects one specific thing: an attacker must already have local access to the machine. It implies that someone without an account cannot launch this exploit remotely, and security teams assessing patch urgency by CVSS score alone might rate it below a 9.x remote code execution vulnerability.

That framing does not hold here. GhostLock is the second half of a two-stage attack chain that Nebula calls IonStack. The first component is CVE-2026-10702, a flaw in IonMonkey — Firefox's just-in-time JavaScript compiler — that allows a malicious webpage to execute code inside the browser and escape Firefox's sandbox. Mozilla's advisory for CVE-2026-10702 That vulnerability was patched in Firefox 151.0.3 on June 2, 2026.

Chained together, IonStack eliminates the local-access precondition entirely. A single tap on a malicious link in Firefox on Android was sufficient to escalate to full device control in Nebula's demonstration — no prior account required. The "local-only" classification that produces GhostLock's 7.8 CVSS rating applies to the vulnerability in isolation; in a chained scenario, it functions as a remote root compromise triggered by visiting a webpage. Nebula has demonstrated the full Android chain; a complete write-up is forthcoming. Systems running unpatched Firefox alongside an unpatched Linux kernel face a combined risk that the 7.8 score does not communicate.

GhostLock's container escape component is what elevates the threat from a server hardening problem to a concern for every organization running cloud-native infrastructure. Containers — as used in Docker, Kubernetes, and virtually every cloud-native deployment — rely on Linux kernel namespaces and control groups for isolation. They do not run separate kernels. A vulnerability in the host kernel reachable from inside a container collapses the security boundary entirely.

In Nebula's testing, the GhostLock exploit succeeds from inside a container without requiring any special container capabilities or elevated privileges. An attacker who gains a foothold inside a containerized workload — through a vulnerable web application, a supply chain compromise, or a malicious CI/CD job — can use GhostLock to escape to the host, gain root on the underlying node, and from there pivot to adjacent workloads sharing the same Kubernetes node. In multi-tenant cloud environments, that pivot potentially reaches other customers' workloads on the same physical host.

Cloud operators, platform engineers, and DevSecOps teams should treat GhostLock as a critical-priority item rather than a routine patch-cycle update. CI/CD pipeline runners and shared Kubernetes nodes — environments where untrusted or semi-trusted code executes under ordinary user accounts — face the most immediate exposure.

Patching GhostLock is not a single step, and teams that apply the first available kernel update may not be fully protected. The initial upstream fix (commit 3bfdc63936dd) resolved the root cause by correcting remove_waiter() to use waiter->task instead of current. However, that patch missed a narrow edge case: a non-top requeue waiter that already owns the target PI futex can hit the deadlock rollback before waiter->task is set, causing a null-pointer dereference. A follow-up fix addressed that secondary bug (CVE-2026-53166), and the complete remediation was still settling upstream as of early July 2026. Early builds from some distributions may include only the initial partial fix.

Practical guidance for security and infrastructure teams:

Install the current kernel from your distribution's security channel rather than assuming the first available post-advisory update is the final one. Confirm the specific fixed package version against your distribution's security bulletin. Ubuntu's newest release and some cloud-optimized kernel builds had been patched as of July 8, but Ubuntu 24.04 LTS, 22.04 LTS, and 20.04 LTS were still listed as vulnerable or in progress.

Two kernel build options — RANDOMIZE_KSTACK_OFFSET and STATIC_USERMODE_HELPER — complicate exploitation but do not eliminate it. RANDOMIZE_KSTACK_OFFSET turns the stack-reuse step from a deterministic operation into a roughly 1-in-32 guess; STATIC_USERMODE_HELPER blocks the specific DirtyMode technique Nebula used but leaves alternative paths open. Neither substitutes for patching.

There is no operational workaround. The threading operations that trigger GhostLock — standard FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI system calls — are used by ordinary multithreaded applications including databases, JVMs, and server software. Blocking them would break normal workloads.

Prioritize shared and multi-tenant machines first: cloud servers, container hosts, CI/CD runners, and any system where an attacker is most likely to already hold a low-privilege foothold. Single-user workstations present lower urgency because the local access requirement is harder for an external attacker to satisfy without the Firefox chain.

GhostLock is the second significant Linux kernel vulnerability found by an AI-driven discovery system in the span of a few weeks, and its emergence alongside Bad Epoll (CVE-2026-46242) makes the pattern visible. Bad Epoll and AI vulnerability discovery Nebula's VEGA platform identified GhostLock in the rtmutex priority-inheritance code — a subsystem that dates to Linux 2.6.18 (2006) and had not been subjected to rigorous automated analysis.

Bad Epoll, disclosed days before GhostLock, arose from the same broader dynamic: a single 2023 commit introduced two separate race conditions into 2,500 lines of epoll code. Anthropic's Mythos model — a frontier AI system used in Project Glasswing — found the first of the two bugs and missed the second. A human researcher, Jaeyoung Chung, found Bad Epoll independently. The two cases together illustrate the current state of AI-assisted security research: capable of finding bugs in old, heavily used kernel subsystems that manual review missed for years, not yet capable of exhaustively auditing every code path it examines.

The through-line connecting GhostLock, Bad Epoll, and Copy Fail — the latter already confirmed in active real-world attacks and listed on CISA's Known Exploited Vulnerabilities catalog — is old kernel machinery that accumulated subtle logic errors over years of incremental development and was rarely subjected to deep, systematic review. Copy Fail on CISA's Known Exploited Vulnerabilities catalog Automated analysis is now reaching code that human audits missed for a decade and a half.

GhostLock's specific combination of attributes is uncommon even within the recent wave of Linux privilege escalation disclosures. Copy Fail, by comparison, required the algif_aead cryptographic module and used a deterministic page-cache write — easy to block by disabling the module in environments that do not need it. Bad Epoll depends on a race condition with a timing window only six instructions wide, making it harder to exploit reliably despite its 99% success rate in the researcher's implementation.

GhostLock requires nothing beyond CONFIG_FUTEX_PI=y, which Nebula confirms is enabled by default across every distribution it researched. The threading operations that trigger it are routine. The 97% reliability comes not from winning a tight race but from a wide UAF window with no time pressure. And the container escape — not present in Copy Fail or most other 2026 LPE flaws — makes GhostLock the more dangerous primitive for cloud-native environments specifically.

Detail Value CVE CVE-2026-43499 Introduced Linux 2.6.39 (May 2011) Fixed upstream Linux 7.1 CVSS Score 7.8 (High) Exploit reliability 97% Exploit time ~5 seconds Bug bounty awarded $92,337 (Google kernelCTF) Privileges required None (any local user) Container escape Yes In-the-wild exploitation None confirmed as of July 8, 2026

Any system running an unpatched Linux kernel with CONFIG_FUTEX_PI enabled is vulnerable — which means desktops, servers, cloud virtual machines, and container hosts alike. The practical risk differs by environment: on a single-user desktop, an attacker needs to have already logged in or gained some form of local access to exploit GhostLock. On a shared server, cloud VM, or multi-tenant Kubernetes node, any compromised process running under any ordinary user account is sufficient. Desktop users should still patch, but shared infrastructure should be treated as the emergency.

CVSS scores each vulnerability individually. Alone, GhostLock requires local access, which limits its score to 7.8 "High" rather than a 9.x "Critical" remote code execution rating. The IonStack chain — combining CVE-2026-10702 (a Firefox JIT flaw, patched June 2) with GhostLock — eliminates that local-access requirement. Visiting a malicious webpage in unpatched Firefox is enough to trigger the full chain. The CVSS score reflects the component; the real-world risk reflects the chain. The correct response to a 7.8 kernel LPE with a public exploit is to treat it as though it were much higher.

No confirmed in-the-wild exploitation had been reported as of July 8, 2026. However, the public exploit code makes detection harder, not easier: GhostLock, like many kernel LPE exploits, uses standard system calls (clone, setsockopt, pselect, futex variants) that are difficult to distinguish from normal application behavior in standard audit logs. Organizations with kernel-level monitoring tools such as Falco or eBPF-based detection can look for unexpected privilege escalation patterns and unusual FUTEX_CMP_REQUEUE_PI call sequences. The most reliable protective measure is patching before exploitation begins.

A use-after-free occurs when code continues to reference a memory location after that memory has been freed and returned to the allocator. In userspace, this typically causes a crash. In kernel space, it is far more dangerous: the freed memory may be reallocated to a different kernel data structure, meaning reads through the stale pointer leak sensitive kernel data and writes through it corrupt arbitrary kernel objects. GhostLock's specific variant — a stack use-after-free — is rarer and in some ways more powerful than heap use-after-frees because the attacker can precisely control what bytes land on the freed stack frame by triggering a subsequent system call, making the primitive highly reliable without requiring heap spray techniques.