Same Story, New Bug: GhostLock and the Summer of Linux Root Exploits

Regular readers of this blog know the pattern by now. A researcher (or, increasingly, an AI-driven fuzzing tool) finds a way to turn an ordinary, unprivileged local process into root on a Linux box, a CVE gets assigned, distributions scramble to ship a patched kernel, and hosting providers running multi-tenant infrastructure spend a few tense days patching and rebooting fleets before anyone can prove it's being exploited in the wild. We wrote about two of these this spring: Copy Fail in late April, and DirtyFrag a week after that.

This week it's GhostLock — CVE-2026-43499 — and it's a good reminder that this isn't a spring anomaly, it's a trend. The kernel's oldest, most heavily used code paths are getting reread by automated tools for the first time in years, and they keep finding something.

What GhostLock is

GhostLock is a use-after-free in the Linux kernel's real-time mutex (rtmutex) code, specifically in the futex priority-inheritance path (kernel/locking/rtmutex.c). It was disclosed on July 7 by Nebula Security, whose AI-assisted bug-hunting tool, VEGA, found it. The bug itself has been sitting in the kernel since Linux 2.6.39, released in May 2011 — roughly fifteen years — and affects essentially every mainstream distribution shipped since, because the only prerequisite is CONFIG_FUTEX_PI, a build option that's enabled by default almost everywhere.

The root cause is a classic lifecycle bug: a cleanup function called remove_waiter() was written under the assumption that the thread running it is always the thread that owns the object it's cleaning up. That assumption holds on the normal path. It breaks on a specific requeue-with-priority-inheritance sequence, where the kernel has to unwind a lock request on behalf of a different, sleeping thread after detecting a deadlock. The cleanup clears the wrong thread's bookkeeping and leaves a pointer dangling into a chunk of kernel stack memory that's about to be reused. An attacker who can win that race — using nothing but three futexes and a handful of ordinary threading syscalls — reclaims that freed stack frame, forges a fake kernel structure over it, and turns the dangling pointer into a controlled write. From there it's a short walk to a corrupted function-table pointer, a control-flow hijack, and root.

No exploit, no elevated privileges, no unusual configuration. Any logged-in local user — or any process running as one, including a compromised PHP-FPM worker or a webshell dropped through a vulnerable plugin — can trigger it. Nebula reports their exploit produces a stable root shell 97% of the time, in about five seconds, and that it also works from inside a container to escape to the host. Google's kernelCTF program paid out $92,337 for the submission. CVSS score is 7.8 (High) — not Critical, because it does require local code execution to start from, but on a shared host that's a bar attackers clear constantly.

The upstream fix is mainline commit 3bfdc63936dd, with a necessary follow-up tracked separately as CVE-2026-53166 — both are required for a complete fix, so if you're checking patch status, check for both CVEs.

Why this matters for hosting environments

This is the part that should sound familiar from our Copy Fail and DirtyFrag coverage. GhostLock doesn't need a sophisticated attacker with a zero-day. It needs an ordinary, everyday foothold: a vulnerable WordPress plugin, an outdated CMS, a webshell from a phishing hit, a leaked credential. Once an attacker has any unprivileged code execution on a shared server — which is to say, once one customer's site has been compromised, which happens on shared hosting infrastructure every single day — GhostLock is the difference between "one hacked site" and "every tenant on this box is compromised." There's no CageFS boundary, no per-tenant isolation, no jail that stops it, because the trigger is a plain futex syscall available to any local process, sandboxed or not.

There is no practical runtime mitigation. CONFIG_FUTEX_PI can't be disabled on a running server without breaking priority-inheritance mutexes that ordinary applications rely on, and there's no module to blacklist or sysctl to flip. The one narrow exception: for containerized or sandboxed workloads specifically, a seccomp policy blocking FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, and FUTEX_CMP_REQUEUE_PI closes the trigger — but it will also break any workload that legitimately uses priority-inheritance mutexes, and it's not a host-wide fix. For everyone else, the patched kernel is the only real answer.

Patch status

As of this week:

• CloudLinux — every supported version is affected (CL7, CL7h, CL8, CL8 LTS, CL9, CL9 LTS, CL10, and CloudLinux for Ubuntu 22.04). Patched kernels for CL7h and CL8 are rolling out from the testing channel to stable; CL9/CL10 track the AlmaLinux kernel builds below; a KernelCare livepatch for the CL9/AlmaLinux 9 family is in the testing feed with wider rollout expected shortly after. Full version numbers and update commands are in CloudLinux's advisory.
• AlmaLinux — all three supported releases (8, 9, 10) are affected. AlmaLinux made the call to ship patched kernels ahead of upstream CentOS Stream/RHEL, and has them in the testing repository now (AlmaLinux 8: kernel-4.18.0-553.141.2.el8_10+; AlmaLinux 9: kernel-5.14.0-687.23.2.el9_8+; AlmaLinux 10: kernel-6.12.0-211.31.2.el10_2+), with a call for community testing before promotion to production. See AlmaLinux's blog post.
• Red Hat / CentOS Stream — tracked on Red Hat's CVE page; check that page directly for your RHEL version's fix status rather than assuming a build number.
• Ubuntu — patched in the newest release and some cloud kernel images; as of early this week 24.04, 22.04, and 20.04 LTS were still listed as vulnerable or in progress. Check Canonical's advisory for your specific series before assuming coverage.

If you run any of these, don't just take the first patched build and call it done — the initial fix introduced a separate, narrower crash bug that got its own CVE (2026-53166), and the cleanup for that was still settling upstream in early July. Confirm you're on a build that addresses both.

Not an isolated incident

GhostLock is also, structurally, half of something bigger. Nebula calls it IonStack: GhostLock is the second stage, carrying a Firefox sandbox escape (CVE-2026-10702) the rest of the way to full root. Nebula has already demonstrated the complete chain — a single tap on a malicious link leading to full device compromise — against Firefox on Android, with a full write-up of that exploit still to come. That's the pattern worth internalizing: a "local-only" kernel bug that looks low-severity in isolation becomes a remote, zero-click compromise the moment it's bolted onto a browser exploit that gets you the initial foothold.

It also isn't the only kernel-to-root bug to surface this year. GhostLock was disclosed within days of Bad Epoll (CVE-2026-46242), another unprivileged-to-root bug in a similarly old, similarly under-reviewed corner of the kernel, and it follows the Copy Fail and DirtyFrag bugs we covered in April and May. The throughline across all of these: old kernel code, heavily used, rarely reread by human eyes — until an automated tool started combing through it. That's not a one-time event. It's a new source of findings, and there will be more of these.

What we're doing, and how we can help

We can't patch your kernel for you, and — same as with Copy Fail and DirtyFrag — GhostLock isn't a bug that lives at the layer Monarx primarily defends. It's a kernel issue, and the fix is the patched kernel or a livepatch, full stop.

What we can do is help with the part that comes before and after the kernel exploit: the application-layer foothold that makes GhostLock reachable in the first place, and the on-disk cleanup after a server's been touched.

• Catching the foothold before it becomes a launchpad. GhostLock needs some unprivileged local code execution to start from. On the servers we protect, that foothold is almost always a webshell, a malicious plugin, or a backdoored theme file sitting in the exact directories ThreatShield and our agent already watch. Stopping that upload or catching that webshell early is one fewer opportunity for an attacker to ever reach the kernel bug at all.
• Surfacing what a rooted server leaves behind. If a host has already been touched — via GhostLock, Copy Fail, DirtyFrag, or anything else — the "Most Infected Users" and "Files" views in the Monarx dashboard, filtered for file.owner: root, are the fastest way to find root-owned malware, persistence mechanisms, and post-exploitation artifacts across your fleet.
• Expanding coverage where you need it. As with the last two incidents, our agent's default paths cover where customer sites and applications live. For servers where you suspect a deeper compromise, Monarx can be configured to scan additional root-owned and system-level paths — see our Advanced Agent Configuration guide.

The caveats are the same ones we gave for Copy Fail and DirtyFrag, and they're worth repeating because they matter: we can identify and help remediate malicious files on disk, but we cannot un-root a compromised server, and we do not terminate root-owned processes. A server rooted via a kernel LPE needs a real incident response process — checking for in-memory implants, active sessions, and stolen credentials — not just a file cleanup. On fully rooted hosts, restoring from a known-good backup remains the industry best practice; Monarx can help bridge the gap while that work is staged.

If you're a Monarx customer patching kernels across a fleet this week and want help figuring out whether anything's already landed on affected servers, our platform aims to facilitate such triage workflows and can surface root owned malware as an indicator of root compromise:

‍

• Dashboard -> Most Infected Users -> filtered by root. This will surface hosts with root owned malware
  
  

• Dashboard -> Most Infected Users -> Upsell Leads. This feature exports data on a CSV file which can be filtered offline (using CSV compatible editors such as Microsoft Excel, Google Sheets, etc) by a file owner (root) and will surface corresponding server/host along with which are eligible for Monarx Active Protection and which aren't.
  
  

• Files -> filtered by most recent and root as user will surface recent instances as a signal of ongoing activity
  
  

‍

However, if you still have questions or want help on a specific use-case, do not hesitate to reach out to your account team or contact us directly.

If you're not a customer but you're running web hosting infrastructure and you're concerned about malware, reach out anyway — this is exactly the kind of work our team does daily, and we're glad to help.

Remember:

• Patch the kernel.
• Check for both CVEs.
• Run a full malware scan on your servers.

‍

We'll keep tracking what surfaces next — because at this rate, something will.

‍