Check your kernel version now: 15-year-old security ghost in the Linux machine

You may not believe in ghosts, but you need to believe in GhostLock if you take your Linux system security seriously.

The kernel vulnerability, formally known as CVE-2026-43499, allows an already logged-in attacker to gain root on any unpatched machine. If that doesn’t scare you, maybe the fact that the GhostLock code has been sitting right there in almost every Linux distribution since 2011 will get the hairs standing up on the back of your sysadmin neck.

As ghost stories go, you might well be thinking this isn’t so spooky. Especially when you take into consideration that kernel exploits tend to carry an operational cost for attackers, in that they often crash the box and burn the access anyway.

But “tend” and “often” are doing a lot of heavy lifting here. Researchers at Nebula have published a working root exploit that can escape containers, and which has earned them a whopping $92,337 by way of the Google kernelCTF bug bounty program.

As Daniel Bechenea, Security Manager at Pentest-Tools.com, put it: “An exploit that Nebula reports as 97% reliable, with public code anyone can run… changes that math” when it comes to offensive operational cost.

GhostLock’s root of attack

So how does it work? To start with, an attacker only needs a low-privilege foothold on a target Linux system. That could be a webshell on an app server, a malicious dependency executing in a build pipeline, or even direct SSH access. Once the attacker has that foothold, they “only” need to get root next to strike.

But getting root is the problem, and it’s mostly solved by GhostLock it would seem.

“As GhostLock uses a kernel vulnerability, containers also represent a juicy target for attackers as the exploit escapes the container and obtains code execution as root on the host OS,” Bechenea told TechFinitive, meaning that “containerised workloads that teams treat as isolated become stepping stones to the host and everything else scheduled on it”.

Although CVE-2026-43499 was patched in April, that doesn’t mean your systems are safe, as there remains some lag in update availability across custom distributions. You should therefore take immediate steps to ensure that your distro has the latest patch, 3bfdc63936dd, installed and that all virtual machines and containers are running an updated version.

“On an unpatched host, treat any code execution as root, and plan containment accordingly,” Bechenea advised.

“Prioritise the systems that run untrusted or semi-trusted code by design: CI runners, container platforms, shared development machines, multi-tenant hosts, and verify the fixed kernel package version on each system rather than trusting that the April fix propagated.”

More security articles by Davey Winder

• When AI agents attack: JADEPUFFER agentic ransomware raid deploys AI from start to finish
• Confirmed: Klue’s integration with Salesforce exposed LastPass customer data (and there are lessons for us all to learn)
• DragonForce ransomware backdoor weaponises legit Microsoft Teams servers