> ## Documentation Index
> Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# GhostLock (CVE-2026-43499): Fifteen Years of Kernel, Root in Five Seconds

> A use-after-free in the kernel futex priority-inheritance path turns any local user into root and escapes containers. No workaround — only a reboot.

*Published on August 8, 2026*

<Warning>
  **CVE-2026-43499 — nicknamed "GhostLock".** A public exploit reaches root from an unprivileged account in about five seconds. There is no runtime mitigation: the only fix is a patched kernel followed by a reboot.
</Warning>

## The bug in two sentences

The flaw is a use-after-free in the kernel locking subsystem, on the futex priority-inheritance path — the machinery behind glibc's `PTHREAD_PRIO_INHERIT` mutexes. A cleanup step in `remove_waiter()` clears the wrong thread's bookkeeping, leaving a live thread pointing at memory that has already been freed.

The freed object sits on the kernel stack rather than the heap, which is where most bugs of this class live. That detail is what makes the exploit so reliable.

The only prerequisite is `CONFIG_FUTEX_PI=y`, enabled by default in every major distribution. The code was introduced in Linux 2.6.39-rc1 in May 2011 and remained vulnerable through v7.1-rc1 — so effectively every production kernel of the last fifteen years qualifies.

## Why this one is different

Local privilege escalations are common and usually rank low on the priority list. Two properties push this one up.

**The exploit is public and it works.** The published full chain reaches root in roughly five seconds at about 97% reliability. That is not a proof of concept requiring a specific kernel build and a favourable wind — it is a working tool.

**It escapes containers.** An unprivileged process inside a container reaches root on the host. If you run untrusted or third-party workloads in containers on a shared node, the isolation you are relying on is not there.

## Sizing your exposure

The question is not the CVSS score — it is 7.8, and that number tells you little here. The question is: **who can execute code on your machine?**

| Profile                                                                   | Exposure                | Action                                               |
| ------------------------------------------------------------------------- | ----------------------- | ---------------------------------------------------- |
| Single-tenant VPS, your code only, no shell accounts for third parties    | Moderate                | Patch during your next maintenance window            |
| VPS with several shell accounts, customers, or an unaudited CI runner     | **Critical**            | Patch and reboot now                                 |
| Docker or Kubernetes node running third-party images or dynamic workloads | **Critical**            | Patch every node — container isolation does not hold |
| Shared hosting where you do not manage the kernel                         | Handled by the provider | Nothing to do on your side                           |

Note the pattern: the flaw needs a local foothold. It is not remotely exploitable on its own. But it turns any modest foothold — a compromised web application, a leaked low-privilege account, a hostile dependency in a build — into full control of the machine.

## There is no workaround

This is the part that trips people up. Red Hat's bulletin states it plainly: no runtime kernel parameter and no module can be disabled to address the flaw. `CONFIG_FUTEX_PI` is compiled into standard builds and cannot be toggled while running.

Unlike a flaw confined to a loadable module, you cannot buy yourself a week with a `modprobe` blacklist. Patch and reboot, or stay vulnerable.

## Patching

### Debian, Ubuntu and derivatives

```bash theme={null}
# Pull the security updates and upgrade the kernel
sudo apt update
sudo apt full-upgrade

# The new kernel is only active after a reboot
sudo reboot
```

Check your distribution's tracker for the exact fixed package version: [Ubuntu](https://ubuntu.com/security/CVE-2026-43499) and [Debian](https://security-tracker.debian.org/tracker/CVE-2026-43499).

### AlmaLinux, Rocky Linux and RHEL

```bash theme={null}
sudo dnf clean metadata && sudo dnf upgrade
sudo reboot
```

Fixed kernel versions on AlmaLinux, or any later release:

| Release      | Fixed kernel                     |
| ------------ | -------------------------------- |
| AlmaLinux 8  | `kernel-4.18.0-553.141.2.el8_10` |
| AlmaLinux 9  | `kernel-5.14.0-687.24.1.el9_8`   |
| AlmaLinux 10 | `kernel-6.12.0-211.32.1.el10_2`  |

Red Hat's bulletin covers RHEL 6 through 10, along with OpenShift, OpenStack Platform, RHEL CoreOS, and every product built on the RHEL kernel.

### Verify the running kernel

Installing the package is not the same as running it. Confirm after the reboot:

```bash theme={null}
# Must show the patched version, not the one you booted this morning
uname -r

# How long the machine has been up — a large value after "patching" is the tell
uptime -p
```

<Note>
  On a Kubernetes cluster, a node is only fixed once it has rebooted. Drain, reboot, uncordon, one node at a time — a patched package on a node that has not rebooted still runs the vulnerable kernel.
</Note>

## Timeline

The handling was orderly, which is worth noting: the flaw was reported on 18 April by Nebula Security, fixed upstream two days later in commit `3bfdc63936dd`, backported on 4 May, and only disclosed publicly on 7 July. Distributions had their patches ready before the details were out.

The exploit followed within a day of disclosure. If your servers have not rebooted since early July, assume the window has been open the whole time.

## If you suspect a compromise

A successful local escalation leaves few marks, and a root-level attacker can erase what does exist. Do not try to clean the machine in place.

The reliable route is to rebuild from a known-good state: deploy a fresh instance, restore your data from a backup predating the suspicion, rotate every credential the machine held — SSH keys, API tokens, database passwords. Your [snapshots](https://help.onetsolutions.net/vps/snapshot) and [backups](https://help.onetsolutions.net/vps/backup) exist for exactly this.

<Tip>
  Reboots after a kernel update are the single most-skipped step in server maintenance. If you manage more than a handful of machines, an inventory of `uname -r` values is worth more than any scanner.
</Tip>

Need a hand sizing up your fleet? [Our team is available](https://help.onetsolutions.net/console/support) from your client area.