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

📋 TL;DR — last updated September 16, 2026, 08:00 UTC

GhostLock (CVE-2026-43499, CVSS 7.8 High) is a use-after-free bug in the Linux kernel’s futex priority-inheritance path that lets any local unprivileged user become root. A public full-chain proof-of-concept exists.

• Affected: every supported CloudLinux version. → Affected versions
• Mitigation: none practical; the fix is a patched kernel or a KernelCare livepatch. → Is there a mitigation?
• Fix status → Update instructions
• — Stream 1 — CloudLinux kernel (CL7, CL7h, CL8): on the stable channel.
• — Stream 2 — AlmaLinux kernel (CL9, CL10): in the AlmaLinux production repositories.
• — Stream 3 — TuxCare ELS kernel (CL8 LTS, CL9 LTS): in the TuxCare ELS stable repository.
• — Stream 4 — KernelCare livepatch (all affected versions): on the main feed for CloudLinux 7, 7h, 8, 9, 9 LTS, 10 and CloudLinux for Ubuntu 22.04. CloudLinux 8 LTS gets no livepatch; it takes the fixed ELS kernel instead, which is already available. On CloudLinux 7, kernel builds lve1.5.79 and older have no livepatch — take the kernel update instead.
• Verify: check uname -r against your stream’s target version, or run kcarectl --patch-info | grep CVE-2026-43499. → How to verify you are patched
• Why it matters: on a shared host, GhostLock is the difference between one hacked site and a compromised server. → Why this matters on a shared host
• How the bug works: a use-after-free in the kernel’s rtmutex futex priority-inheritance cleanup path. → Technical details of the bug

Live rollout status is tracked on the CloudLinux status page.

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.

💡 Another kernel reboot cycle?

GhostLock is the latest in a run of Linux kernel privilege-escalation issues that have each required a patch and a reboot on affected hosts. If emergency-patching and rebooting servers on this cadence is not sustainable for you, KernelCare is the alternative we recommend. It applies kernel security fixes to a running server automatically, with no reboot and no maintenance window. Once the GhostLock livepatch reaches the main feed, servers running KernelCare receive it on the next update cycle. See Stream 4 below for current status.

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. Canonical has published the fixed kernel: linux 5.15.0-187.197 or newer — install it with apt update and apt upgrade, then reboot. The KernelCare livepatch (Stream 4) is the no-reboot alternative.

‡ On CloudLinux 7 the livepatch covers kernel builds lve1.5.80 through lve1.5.88. A server running lve1.5.79 or older has no livepatch for that build and needs the kernel update instead — see Stream 1.

A KernelCare livepatch is available as a no-reboot alternative on every affected version except CloudLinux 8 LTS, which takes the fixed ELS kernel instead.

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)

Update: July 22, 2026, 11:33 UTC.

Patched CloudLinux kernels promoted to stable — a plain yum update 'kernel*'; reboot now pulls the fix, no testing-repo flag needed:

• CL7: kernel-3.10.0-962.3.2.lve1.5.89.el7
• CL7h: kernel-4.18.0-553.141.2.lve.el7h
• CL8: kernel-4.18.0-553.141.2.lve.el8

Update: July 10, 2026, 20:00 UTC.

The patched CloudLinux 7 kernel is in the beta/testing channel and rollout to stable has started. Install from the testing channel now (commands below), or take the update once it reaches the stable channel:

• CL7: kernel-3.10.0-962.3.2.lve1.5.89.el7 or newer

Update: July 9, 2026, 11:30 UTC.

Patched CloudLinux kernels for CL7h and CL8 are in the beta/testing channel and rollout to stable has started. Install from the testing channel now (commands below), or take the update once it reaches the stable channel:

• CL7h: kernel-4.18.0-553.141.2.lve.el7h or newer
• CL8: kernel-4.18.0-553.141.2.lve.el8 or newer

Status: July 8, 2026, 18:00 UTC.

Patched CloudLinux kernels for CL7, CL7h and CL8 are being prepared. Target versions will be added here on release to the beta/testing channel.

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)

Update: July 22, 2026, 11:33 UTC.

AlmaLinux 9 and AlmaLinux 10 patched kernels in production repositories. Target versions:

• AL9: kernel-5.14.0-687.24.1.el9_8 or newer (current: 687.26.1)
• AL10: kernel-6.12.0-211.32.1.el10_2 or newer (current: 211.34.1)

Update: July 9, 2026, 15:00 UTC.

AlmaLinux 8/9/10 patched kernels are now in the production repositories:

• AL8: kernel-4.18.0-553.141.2.el8_10 or newer
• AL9: kernel-5.14.0-687.24.1.el9_8 or newer
• AL10: kernel-6.12.0-211.32.1.el10_2 or newer

Testing repo activation is no longer needed — a plain dnf clean metadata && dnf upgrade; reboot picks up the fix.

Update: July 9, 2026, 11:30 UTC.

AlmaLinux has published patched kernels to its testing repository. Install from testing now (commands below), or take them from the production repositories once promoted:

• CloudLinux 9 / AlmaLinux 9: kernel-5.14.0-687.23.2.el9_8 or newer
• CloudLinux 10 / AlmaLinux 10: kernel-6.12.0-211.31.2.el10_2 or newer

Status: July 8, 2026, 18:00 UTC.

CloudLinux 9 and 10 track the AlmaLinux kernels. AlmaLinux is preparing patched kernels. Target versions will be added here on release to the testing repository.

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)

Update: July 30, 2026, 10:00 UTC.

The patched kernel-lts package is released to the TuxCare ELS stable repository for both LTS platforms:

• CL8 LTS: kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els8 or newer
• CL9 LTS: kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els8 or newer (uname -r reports 5.14.0-284.1101.el9_2.tuxcare.11.els8)

The matching LTS LVE module, kmod-lve-lts-2.1-72, shipped in the same release. Update both in the same run (commands below).

Status: July 8, 2026, 18:00 UTC.

The patched kernel-lts package for CloudLinux 8 LTS and CloudLinux 9 LTS is being prepared. Target versions will be added here on release.

ELS-subscribed customers install from the TuxCare ELS repository, updating the LTS LVE module (kmod-lve-lts) in the same run. This pipeline is separate from the stock CL8/CL9 kernel rebuild above.

yum update kernel-lts kmod-lve-lts
reboot

Stream 4: KernelCare livepatch (all affected versions)

Update: July 31, 2026, 13:09 UTC.

The KernelCare livepatch for GhostLock is now on the main feed for CloudLinux 7, CloudLinux 7h, CloudLinux 8, CloudLinux 9 (including AlmaLinux 9 and CloudLinux 9 LTS), CloudLinux 10, and CloudLinux for Ubuntu 22.04. Nothing in the CloudLinux family is testing-only at this point, so a subscribed server takes the patch on its next update cycle, or on demand:

kcarectl --update

One caveat on CloudLinux 7. The livepatch covers kernel builds lve1.5.80 through lve1.5.88 only. On a CloudLinux 7 server running lve1.5.79 or older there is no livepatch for that build, and the kernel update is the only route — those kernels are already on the stable channel:

yum update 'kernel*'
reboot

Check which build you are on with uname -r.

Update: July 13, 2026, 16:00 UTC.

KernelCare livepatches are now in the main feed for CloudLinux 7h, 8, 9 (with AlmaLinux 9), and CloudLinux for Ubuntu 22.04. Subscribed servers receive them automatically on the next update cycle.

Update: July 10, 2026, 20:00 UTC.

The CloudLinux 7 KernelCare livepatch is now in the testing feed, with promotion to the main feed to follow.

Update: July 10, 2026, 12:00 UTC.

The CloudLinux 10 / AlmaLinux 10 KernelCare livepatch is now in the testing feed, with promotion to the main feed to follow.

Update: July 10, 2026, 11:00 UTC.

GhostLock is closed by the primary upstream fix (CVE-2026-43499) alone. The follow-up commit tracked as CVE-2026-53166 was reverted upstream after it caused a regression, so it is not part of the fix; verify with kcarectl --patch-info | grep CVE-2026-43499 (see How to verify below).

KernelCare livepatches for CloudLinux 9 and CloudLinux 9 LTS are now in the main feed. The remaining families are following, and subscribed servers receive them automatically on the next update cycle.

Update: July 9, 2026, 16:00 UTC.

The first GhostLock KernelCare livepatches for the CloudLinux 9 / AlmaLinux 9 family are now in the testing feed and are expected to reach the main feed within hours. Once they promote to the main feed, subscribed CloudLinux 9 servers receive them automatically on the next update cycle. Livepatches for the remaining affected CloudLinux families are still in preparation.

Status: July 8, 2026, 18:00 UTC.

KernelCare livepatches for GhostLock (CVE-2026-43499 and CVE-2026-53166, shipped together) are in preparation for the affected CloudLinux families. Once released to the main feed, subscribed servers receive the patch automatically on the next update cycle.

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

⚠ Do not use kcarectl --info | grep CVE-... for verification. That form returns empty output even on correctly patched systems. Always use kcarectl --patch-info for CVE-level status.

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