GhostLock and the Case Against the Shared Kernel

CVE-2026-43499, nicknamed GhostLock, is a use-after-free in the Linux kernel's rtmutex priority-inheritance handling that can be triggered through the futex requeue path. It can allow an unprivileged local user to gain root on an affected system, and NVD rates it 7.8 High. 1

On a machine you control alone, it is a serious bug that should be patched promptly. On a multi-tenant server it is, in CloudLinux's phrasing, "the difference between one hacked website and a compromised server". Their advisory is blunt about what "local" means here: not an insider or a customer you trust, but 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. 2

Same bug, two completely different consequences. The vulnerability is identical. The impact depends on the isolation model.

It hasn't been a quiet stretch for the kernel more generally. CVE-2026-52921, rated 5.5 Medium, affects the way several netfilter ipset hash variants iterate IPv4 ranges: the 32-bit iterator can advance past the end of the requested range, so a retry resumes from an unintended position. 3 Bugs like that rarely get the attention a remote exploit does, and they still bear on whether a security control behaves the way you configured it.

Where your isolation boundary sits

Most hosting buyers never ask where the isolation boundary actually sits, and it's the thing that determines what a local root exploit costs them.

On shared hosting you share a kernel and the underlying operating system with many other customers, and isolation depends on filesystem permissions, service configuration and whatever additional controls the provider has layered on.

On containers, OpenVZ or LXC you share a kernel, and isolation is namespaces and cgroups: a software boundary inside one running kernel. A kernel-level privilege escalation is, by construction, an escape from a boundary implemented by that same kernel.

Under full virtualisation with KVM you don't share a kernel. Each guest runs its own, and isolation is enforced by the CPU's virtualisation extensions and the hypervisor. A local root exploit inside a KVM guest normally gives control of that guest only, which is already the boundary the customer paid for.

That distinction is the key architectural difference. Under KVM, GhostLock gives an attacker root on a machine where root is a thing you can buy for €5. It doesn't give them the machine next door.

Not a claim of invulnerability

This is also where hosting claims often become too broad.

KVM isn't immunity. Hypervisor escapes exist, they're rarer and far more expensive to develop, and a compromised host is a compromised host on any platform. We wrote in May about the share of Huntress-observed ransomware cases involving the hypervisor rising from 3% to 25% across 2025, because attackers understand that the host is the high-value target. 4

What KVM changes is the class of bug that gets you across the boundary. A shared-kernel platform is exposed to kernel vulnerabilities reachable from any tenant environment, including the continuous stream of Linux local privilege escalations, of which GhostLock is the latest example. A KVM platform is exposed to hypervisor escapes, which are a much smaller and much harder category.

You're still patching. You're just not one routine kernel CVE away from your neighbours.

Your own kernel, and you can replace it

Every AVS ISP VPS and VDS is full KVM virtualisation. Not OpenVZ, not LXC with a control panel on top. You get your own guest kernel and you can change it: run a different distribution, boot a custom kernel, load your own modules, install a BSD, or run something that isn't Linux at all. The template list is Debian 12 and 13, Ubuntu 22, 24 and 26, AlmaLinux 8, 9 and 10, Rocky Linux 8, 9 and 10, Arch, FreeBSD, Windows Server 2019, 2022 and 2025, and Windows 10 and 11 LTSC. The Windows images need a plan with at least 4 GB of RAM; everything else runs anywhere.

That list isn't a feature bullet so much as direct evidence of where the boundary sits. A shared-kernel platform cannot offer you FreeBSD or Windows at all, because there is one kernel on the machine and it is Linux. Being able to boot either is proof that the kernel is yours to choose.

For operators, the day-to-day differences are concrete. You patch on your own schedule, since GhostLock is a kernel update in your guest rather than a ticket and a wait for a fleet-wide reboot. Your neighbour's patching isn't your problem, because their unpatched kernel is inside their guest. And recovery doesn't require the network, because every VPS and VDS currently in our catalogue has noVNC console access through the client area, so if a kernel update goes wrong you fix it from a screen and keyboard rather than from a support queue.

Plans are €5/mo for a VPS, €40/mo for a VDS with 4 to 16 vCPU, and €150/mo for bare metal. VPS and VDS run in Tirana, Skopje, Amsterdam and London, bare metal in Tirana, Skopje and Amsterdam. Crypto accepted, no KYC, DDoS protection included.

The question to ask before you buy

When a hosting plan says VPS, it doesn't always mean full virtualisation. Container-based products are frequently sold with the same word and a lower price, and the difference is invisible on the order page.

The question worth asking before you buy is this. Can I run my own kernel?

If yes, you have control of your own guest kernel. If no, you're sharing one with everybody else on the box, and every Linux local privilege escalation reachable from that shared kernel is, to some degree, your problem too.

Sources

1. CVE-2026-43499, NVD
2. GhostLock (CVE-2026-43499) Local Root Exploit, CloudLinux
3. CVE-2026-52921, NVD
4. The Hidden Risk in Virtualization: Why Hypervisors are a Ransomware Magnet, BleepingComputer