✅Urgent Security Advisory – GhostLock (CVE-2026-43499) Local Root Exploit: Kernel Update for CloudLinux

Main Link: GhostLock (CVE-2026-43499) Local Root Exploit: Kernel Update for CloudLinux - CloudLinux

GhostLock is a Linux kernel vulnerability that lets any unprivileged local user become root. On a multi-tenant server that is the worst case a hosting provider plans for: a single compromised site, a low-trust shell account, or a hacked plugin can go from an ordinary process to full control of the machine, and every other customer on it, in seconds. A full-chain proof-of-concept has been publicly demonstrated by the researcher. The weaponized exploit code is currently target-specific to arm64 Android devices, while the x86_64 Linux exploit chain is fully described in the writeup and expected to appear in the wild within days.

It was disclosed on July 7, 2026 by the research team VEGA at Nebula Security, in a writeup titled “IonStack part II: GhostLock,” alongside a working proof-of-concept. The researchers report their exploit produces a stable root shell about 97% of the time, in roughly five seconds.

Why this matters on a shared host

On any affected CloudLinux server, GhostLock is the difference between one hacked website and a compromised server. A kernel local privilege escalation turns any code running on the server into root, and “local” here does not mean an insider or a customer you trust. It means any process on the machine, including the PHP-FPM worker behind a compromised WordPress plugin, an outdated CMS, or a site running on leaked credentials. The attacker is whoever hacked one of the sites you host.

On an unpatched host the chain is short, and none of it needs special access:

1. A web-tier compromise. An attacker exploits a vulnerable WordPress plugin, an outdated CMS, or one of the everyday web-application flaws shared hosting sees constantly. They now run as the site’s PHP-FPM or Apache identity, or its CageFS account, in theory confined to that one site.
2. GhostLock. From that unprivileged process, the attacker uses the futex use-after-free to become root. No prior root, no special capability, no admin action.
3. Root on the host. They now run outside every CageFS boundary and every per-tenant limit. Every other tenant’s files, databases, credentials, and backups on that server are within reach, and in the worst case recovery means rebuilding the whole server.

On a patched host, or one running a KernelCare livepatch, step 2 fails: a web-tier compromise stays a web-tier compromise, one site to clean up rather than a whole server to rebuild. That is what the kernel update buys you.

Technical details of the bug

GhostLock is a use-after-free in the Linux kernel’s real-time mutex code, on the futex priority-inheritance path (kernel/locking/rtmutex.c). The routine that unwinds a lock request during cleanup was written on the assumption that the thread doing the cleanup owns the request it is tearing down. A specific requeue-with-priority-inheritance sequence breaks that assumption. When the kernel detects a deadlock and rolls the operation back, it clears the wrong thread’s bookkeeping and leaves a pointer dangling into a freed region of kernel stack. The public exploit reclaims that freed memory, forges a kernel structure inside it, and turns the dangling pointer into a controlled write, which it walks up to a root shell.

The only prerequisite is that the kernel is built with CONFIG_FUTEX_PI, the priority-inheritance futex option. That is the default on every major distribution, and it cannot be turned off on a running server without breaking the standard priority-inheritance mutexes that normal software relies on. No special privileges, capabilities, namespaces, or hardware are required.

The defect is old. It was introduced in Linux 2.6.39 in May 2011, which means essentially every kernel shipped in the last 15 years carries it; the vulnerable range runs from 2.6.39 up to just before 7.1. Fixing it takes two upstream commits, and both are required: 3bfdc63936dd (the primary fix) and its follow-up 74e144274af3, which is tracked separately as CVE-2026-53166.

Details: Nebula Security writeup · public PoC · upstream fix (commit 3bfdc63936dd) · Red Hat CVE-2026-43499 · NVD entry for CVE-2026-43499

Affected CloudLinux versions

GhostLock’s vulnerable range covers every kernel CloudLinux ships, so all supported versions are affected.

A KernelCare livepatch is available as a no-reboot alternative on all affected versions.

Is there a mitigation?

Not a practical one. The bug’s only prerequisite, CONFIG_FUTEX_PI, is a build-time kernel option with no runtime switch, and it cannot be disabled on a running server without breaking the priority-inheritance mutexes that applications depend on. There is no module to blacklist and no sysctl to set.

Per-tenant sandboxing does not close it either. The trigger is the futex system call, which is available from any local process, caged or not.

For containerized or sandboxed workloads only, a seccomp policy that blocks the priority-inheritance futex operations (FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, FUTEX_CMP_REQUEUE_PI) closes the trigger. It also breaks any workload that uses priority-inheritance mutexes, so test before deploying. It is not a general host-wide fix.

The only complete fix is the patched kernel or a KernelCare livepatch. Apply Stream 1, 2, 3, or 4 below as soon as it is available for your platform.

Update instructions

Four delivery streams cover the affected platforms.

Stream 1: CloudLinux kernel (CL7, CL7h, CL8)

Once the patched kernel reaches the beta/testing channel (target versions will be listed above), install it.

For CL7 and CL8:

yum update 'kernel*' --enablerepo=cloudlinux-updates-testing
reboot

For CL7h:

yum update 'kernel*' --enablerepo=cl7h_beta
reboot

Once the kernels reach the stable channel, a plain yum update kernel; reboot is sufficient.

Stream 2: AlmaLinux kernel (CL9, CL10)

Once patched kernels reach the AlmaLinux testing repository, enable it by installing the release-testing package directly from the AlmaLinux repo, update the kernel, then disable the testing repo again.

For CL10:

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-2.el10.x86_64.rpm
dnf update 'kernel*'
reboot
dnf config-manager --disable almalinux-testing

For CL9:

rpm -Uvh --nodeps https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-2.el9.noarch.rpm
dnf update 'kernel*'
reboot
dnf config-manager --disable almalinux-testing

Once the kernels reach the production repositories, a plain dnf update kernel; reboot is sufficient.

Stream 3: TuxCare ELS LTS kernel (CL8 LTS, CL9 LTS)

ELS-subscribed customers install from the TuxCare ELS repository. This pipeline is separate from the stock CL8/CL9 kernel rebuild above.

yum update kernel-lts
reboot

Stream 4: KernelCare livepatch (all affected versions)

Once available, deploy from the testing feed:

kcarectl --update --prefix test

Once promoted to the main feed, subscribed servers update automatically, or on demand:

kcarectl --update

How to verify you are patched

Streams 1, 2, and 3 (kernel update). After updating and rebooting, compare your running kernel against the target version in the relevant stream’s most recent status callout above:

uname -r

Stream 4 (KernelCare). Both fixes are required for GhostLock, so check for both:

kcarectl --patch-info | grep -E 'CVE-2026-43499|CVE-2026-53166'