GhostLock (CVE-2026-43499)

GhostLock (CVE-2026-43499) is a use-after-free vulnerability in the Linux kernel's real-time mutex — rtmutex — priority-inheritance code. The bug lives in the futex PI path in kernel/locking/rtmutex.c, where a cleanup helper called remove_waiter() wrongly assumes the waiter being cleaned up belongs to the currently running task. Under the right conditions that assumption fails, kernel memory is freed while still in use, and an attacker who controls what lands in that freed memory controls the kernel.

The vulnerability was disclosed on 7 July 2026 by the VEGA research team at Nebula Security, who found it with their automated analysis tooling and published a technical writeup titled "IonStack part II: GhostLock" alongside a working proof-of-concept. The numbers in that writeup are what set GhostLock apart from a typical Linux kernel privilege escalation: the researchers report a stable root shell roughly 97% of the time, in about five seconds. Kernel exploits are often fragile, one-in-ten affairs that crash the machine more often than they land. This one is close to point-and-shoot.

CVE-2026-43499 is rated CVSS 7.8 (High). An unprivileged local user — no special capabilities, no group memberships, nothing beyond the ability to run code — can escalate to root. It also works from inside a container to escape to the host, a property we'll come back to, because it matters enormously for shared hosting security. The fix landed in mainline Linux in commit 3bfdc63936dd (Linux 7.1), and distributions are rolling patched kernels now.

The vulnerable code was introduced in 2011, in Linux 2.6.39, and sat unnoticed for roughly fifteen years. That longevity has two practical consequences for anyone running a server today.

First, breadth. GhostLock depends only on CONFIG_FUTEX_PI, a kernel configuration option enabled on essentially every distribution kernel — Ubuntu, Debian, RHEL, AlmaLinux, Rocky, CloudLinux, the lot. There is no unusual module to load, no exotic feature to have switched on. If your server runs a stock distribution kernel from the last decade and a half and hasn't taken this month's patch, it is almost certainly vulnerable. Exposure is as close to universal as Linux kernel bugs get.

Second, humility. A root-level bug hid in one of the most scrutinised subsystems of the most scrutinised open-source project on earth for fifteen years, and was ultimately found by an automated tool rather than a human reviewer. Nobody can promise you a kernel without undiscovered escalation bugs — not EveryHost, not any hosting provider. What can be promised is how fast patches are applied when bugs surface, and how much damage one bug can do given your hosting architecture. Those two things are the whole game, and they're the theme of the rest of this article.

GhostLock is also not arriving alone. It is one of three Linux root-level flaws patched in the same fortnight, alongside Bad Epoll (CVE-2026-46242) and the KVM escape Januscape (CVE-2026-53359). Earlier this year we covered Fragnesia (CVE-2026-46300), another high-severity Linux kernel privilege escalation, and the pattern is the same every time: the kernel will keep producing these, and your process for absorbing them is what actually protects you.

GhostLock is local-only. An attacker must already have shell-level code execution on the server before they can use it — they cannot fire it at your store from the internet. It is tempting to read "local" as "not my problem." For an ecommerce server, that reading is wrong, and it's wrong for the same reason it was wrong with Fragnesia.

Magento 2 is one of the most actively attacked ecommerce platforms in the world, and successful attacks follow a well-worn chain: exploit a vulnerable extension, an unpatched core CVE, or a weak admin credential; drop a webshell running as the web server user (www-data or nginx); then work outward from there. That webshell is precisely the "unprivileged local user" GhostLock requires. A low-privilege foothold that yesterday could only rummage through files the web user owns can, with a public exploit that lands 97% of the time, become root in about five seconds.

From root, an attacker can:

• →Read every customer record, order, and stored payment token on the server
• →Inject Magecart-style card skimmers directly into your checkout code
• →Install persistent rootkits that survive reboots and evade standard malware scans
• →Disable monitoring and tamper with audit logs to hide the compromise
• →On shared or container-based hosting, pivot to every other store on the same node

"Local" doesn't mean low impact. It means "the second step of a two-step attack" — and Magento supplies the first step often enough that an unpatched local escalation with a reliable public exploit is a real, present threat to live stores. We keep a running guide to the web-layer half of that chain in our Magento Security Centre.

A great deal of modern shared hosting isn't old-fashioned cPanel accounts on one filesystem — it's containers. Providers put each customer's store in its own container and describe the result as "isolated." The isolation is real at the filesystem and process level, but every container on a node shares one thing: the host's kernel. A container is a fence, and the kernel is the ground the fence is planted in.

GhostLock goes through the ground. Because the futex priority-inheritance machinery it abuses is available to unprivileged processes inside containers by default, the exploit works from inside a container to escape to the host. Nebula Security's writeup demonstrates exactly that: code running as an ordinary user inside a container ends up with root on the host kernel.

Play that forward on container-based shared Magento hosting. An attacker compromises one store on a node — any store, not necessarily yours — through an abandoned extension or a phished admin password. Their webshell runs GhostLock, escapes the container, and is now root on the host. Every other container on that node — every other store, database, and stored credential — is theirs. Your store can be fully compromised through a vulnerability in a business you've never heard of, whose only connection to you is a shared kernel.

This is the scenario that makes GhostLock a shared hosting security story, not just a patch-Tuesday story. Container isolation is a meaningful defence-in-depth layer, but it is not a security boundary you can bet a card-handling business on when the kernel underneath has a public root exploit.

SSH into your server and run:

uname -r

Compare the kernel version against your distribution's security advisory for CVE-2026-43499:

• Ubuntu: check Ubuntu Security Notices (USN) for CVE-2026-43499
• Debian: check the Debian Security Tracker entry for CVE-2026-43499
• RHEL: see Red Hat security bulletin RHSB-2026-010, which covers CVE-2026-43499 and the related CVE-2026-53166
• AlmaLinux: patched kernels were published on 9 July 2026 — update and reboot
• CloudLinux: a kernel update has shipped — common on cPanel-based shared hosting, so ask your host if you're unsure what you run

If your kernel is older than the fixed version listed by your distribution, you are vulnerable. The fix is to update via your package manager (apt, yum, dnf) and reboot the server. The mainline fix is commit 3bfdc63936dd in Linux 7.1; your distribution will have backported it to its own kernel versions.

Kernel patches are applied on EveryHost servers as part of standard managed UK Magento hosting — customers don't opt in, pay extra, or file a ticket. The fix for CVE-2026-43499 is rolling out across the fleet now, as distribution kernels land.

We are not claiming our Sentinel WAF blocks GhostLock. It doesn't — GhostLock is a kernel bug, not a web-layer one, and no WAF can mitigate it. What Sentinel does is block the web-layer foothold chain: the Magento exploits, webshell uploads, and brute-force attacks against admin endpoints that an attacker needs before GhostLock is even reachable. A privilege-escalation bug with no low-privilege foothold to escalate from is a patch item, not an incident.

And we are not claiming immunity, because there isn't any. GhostLock sat in the kernel for fifteen years; something else is sitting there now. Honest security posture is patch cadence plus defence in depth plus an architecture that contains the blast when — not if — the next one is disclosed.

GhostLock draws the sharpest line yet between shared and single-tenant hosting, precisely because of the container escape. On shared or container-based infrastructure, one tenant's web-layer foothold plus GhostLock's container escape equals every store on the node exposed — kernels are shared, so compromise is shared. The security of your store becomes the security of the least-patched, worst-maintained store you happen to share hardware with.

EveryHost runs single-tenant dedicated Magento servers. Your server runs your kernel, used by nobody else. A GhostLock-class bug on EveryHost still requires patching — we patch — but the blast radius of any kernel-level event is bounded to one customer's site, one customer's data, one customer's reboot window. There is no neighbouring tenant to escape from, and no neighbouring tenant to escape to.

That's not an argument for relaxing about kernel CVEs. It's an argument that the architecture your provider chose years before this disclosure — single-tenant or shared, dedicated or containerised — quietly decided most of your exposure before the VEGA team ever hit publish.