GhostLock (CVE-2026-43499) Local Root Exploit: Kernel Update for 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.

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.

Affected CloudLinux versions

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

^† CloudLinux for Ubuntu takes its kernel fix from Ubuntu (Canonical) via apt, not a CloudLinux stream; apply it once Canonical publishes it. The KernelCare livepatch (Stream 4) is the no-reboot alternative.

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.

Update the LVE kernel module (kmod-lve) in the same run. The patched kernel keeps the same KABI, so a current module stays compatible; but a host coming from a much older kernel can be left with an incompatible kmod-lve. Update both together to avoid a module/kernel mismatch.

For CL7 and CL8:

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

For CL7h:

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

Once the kernels reach the stable channel, a plain yum update kernel kmod-lve; 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.

Update the LVE kernel module (kmod-lve) in the same run. The patched kernel keeps the same KABI, so a current module stays compatible; but a host coming from a much older kernel can be left with an incompatible kmod-lve. Update both together to avoid a module/kernel mismatch.

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*'
dnf update kmod-lve --enablerepo=cloudlinux-updates-testing
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*'
dnf update kmod-lve --enablerepo=cloudlinux-updates-testing
reboot
dnf config-manager --disable almalinux-testing

Once the kernels reach the production repositories, a plain dnf update kernel kmod-lve; 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). kcarectl –patch-info cites only the primary CVE, so finding CVE-2026-43499 confirms GhostLock is patched:

kcarectl --patch-info | grep CVE-2026-43499

Why this matters on a shared 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. The fix is the upstream commit 3bfdc63936dd (CVE-2026-43499). A follow-up commit, 74e144274af3 (tracked separately as CVE-2026-53166), was reverted upstream after it introduced a regression, so it is not part of the shipping GhostLock fix.

References

• Nebula Security writeup: IonStack part II: GhostLock
• Bug-list entry: CVE-2026-43499
• Public PoC: CyberMeowfia/IonStack/CVE-2026-43499
• Upstream fix: commit 3bfdc63936dd
• Red Hat: CVE-2026-43499
• Press coverage: The Hacker News, “15-Year-Old GhostLock Flaw Enables Root”
• NVD entry: CVE-2026-43499
• CloudLinux status page: GhostLock incident