CloudLinux: request review CVE-2026-43499 Ghostlock LPE

Issue

A local privilege escalation vulnerability in the Linux kernel, referred to as "GhostLock" and tracked as CVE-2026-43499 (CVSS 7.8, High), was publicly disclosed on 07/07/26 along with a working proof-of-concept exploit. Customers are asking whether CloudLinux OS kernels are affected and whether a KernelCare patch is available.

Update, 08/07/26: An earlier version of this article stated that CloudLinux OS kernels were not affected. That conclusion was based on Red Hat's CVE advisory as it read earlier the same day. Red Hat has since updated that advisory to list RHEL kernels as Affected. 

Environment

• CloudLinux OS (CL7, CL8, CL9, CL10) 
• KernelCare 
• Any Linux kernel built with CONFIG_FUTEX_PI=y (the default on effectively all major distributions)

Solution

Follow updates on the CloudLinux Blog Post here: https://blog.cloudlinux.com/ghostlock-cve-2026-43499-local-root-exploit-kernel-update-for-cloudlinux/

---

Patch status as of 08/07/26:

1. Check whether your kernel is already fixed. CloudLinux 9 and CloudLinux 10 track the CentOS Stream / AlmaLinux kernel lines, which have already received a fix:

• CloudLinux 9: fixed from kernel-5.14.0-716.el9 onward; vulnerable at kernel-5.14.0-699.el9 and earlier.

• CloudLinux 10: fixed from kernel-6.12.0-239.el10 onward; vulnerable at kernel-6.12.0-224.el10 and earlier.

  Run uname -r to check your current kernel version against the boundaries above. 

• CloudLinux 7 and CloudLinux 8 kernel boundaries are still being confirmed with the vendor.

2. If you use KernelCare, a livepatch for this CVE is in development. Check whether it has been released for your system with:

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

3. Once a livepatch is available, apply it with:

   kcarectl --update

(or kcarectl --update --prefix test to pull it from the testing feed before general release, if you'd like to validate it first). 

4. For containerised or sandboxed workloads, if you need interim hardening before a fixed kernel or livepatch is available, a seccomp profile blocking the futex priority-inheritance operations (FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, FUTEX_CMP_REQUEUE_PI) closes the trigger path. 

Test thoroughly before deploying — this will break any workload that legitimately relies on priority-inheritance mutexes (glibc's PTHREAD_PRIO_INHERIT). 

5. There is no other supported runtime mitigation. 

CONFIG_FUTEX_PI is a build-time kernel option, not a toggle you can disable on a running production system, so outside of the seccomp option above, an updated kernel or KernelCare livepatch is required to fully close this issue.

---

ETA on a patched kernel or live patch?

The KernelCare live patch is the most efficient option, since there is no fixed stock kernel to update to yet. It is in active development but has not reached the patch feeds. Once it is released, you will be able to apply it through KernelCare with no reboot.

We will update this article as soon as fixed kernels or a KernelCare livepatch are confirmed available for CL7, CL8, CL9, and CL10.

Cause

GhostLock is a use-after-free vulnerability in the Linux kernel's futex priority-inheritance (PI) locking code. A cleanup routine assumes the thread calling it owns the object being cleaned up — an assumption that "requeue-PI" futex operations can violate, leaving a pointer dangling into freed kernel stack memory. A local, unprivileged process can use this to escalate to root; no special capabilities or hardware are required.

Useful Links

• CloudLinux Blog Post: https://blog.cloudlinux.com/ghostlock-cve-2026-43499-local-root-exploit-kernel-update-for-cloudlinux/
• Red Hat security advisory: 
  https://access.redhat.com/security/cve/cve-2026-43499
• Red Hat Bugzilla tracking: https://bugzilla.redhat.com/show_bug.cgi?id=2480453