Critical Linux kernel vulnerability leads to full KVM escape
KVM virtual machines were never truly isolated – hackers just didn’t know what code to run. Now they do.

Linux servers vulnerable. Image by Cybernews.
- PwnEscape is a 9.3-rated Linux kernel flaw that can let VM guests compromise host servers.
- Attackers can trigger the bug by sending malformed IPv4 packets from inside a virtual machine.
- The flaw exposes host memory and may allow controlled changes to kernel memory, according to the researcher.
- A Linux kernel fix exists, but some distributions have not yet delivered it to affected systems.
Key Takeaways by nexos.ai, reviewed by Cybernews staff.
A critical vulnerability in the Linux kernel leaves no security boundary between guests and hosts – hackers can escape virtual machines simply by sending network packets, and compromise entire servers. Patched kernels have yet to reach all the affected systems.
Cybernews previously reported that a researcher, Paulos Yibelo, found a massive zero-day bug that allowed a KVM guest-to-host escape. At the time, no technical details were provided.
Now the vulnerability is official, and it is nearly as bad as it can get. The vulnerable component isn’t KVM virtualization technology, but the Linux kernel’s networking stack.
The flaw even got a mischievous tracking ID – CVE-2026-99999. The researcher dubbed it PwnEscape.
“PwnEscape leads to VM escapes across multiple hypervisors due to a super cool Linux networking bug,” Yibelo said on X.
To compromise the entire host, all the attacker needs is to send malformed IPv4 network packets from inside a VM – most programs usually have access to networking. No privileges or user interaction are required, and the attack complexity is low. The bug is rated 9.3 out of 10 on the severity score.
The fix was already accepted on October 8th and merged into the mainline Linux kernel codebase on October 14th. Various Linux distributions have yet to ship it to their users.
How does the exploit work?
For virtual machines to have access to the open internet, the host kernel has to process their traffic. The bug lies in how Linux handles network packets.
Each network packet has a header with information such as where it’s going, how large it is, which protocol it uses, and more. Packets travel the internet with a checksum attached, which allows for checking that the payload arrived uncorrupted.
However, VMs often send packets without a completed checksum, leaving the host kernel to calculate it, thereby saving compute resources. Instead, VMs attach metadata describing what to calculate and where to write the result.
The host kernel’s IPv4 implementation uses a helper called skb_checksum_help to calculate the checksum and write it to the correct place in the packet.
It turns out the kernel doesn’t verify metadata well enough, and attackers can corrupt packets by sneaking in deceptive metadata.
Yibelo demonstrated an exploit that relies on sending a very small packet of just 28 bytes, of which 20 bytes are the IPv4 header. But the metadata tells the kernel to write the checksum in the wrong place – overwriting the original header’s header-length field.
After this operation, the 20-byte header is treated as a longer 60-byte header, while the entire packet still remains just 28 bytes.
The kernel only performed the check once, before the packet was changed, and then kept trusting its earlier result.
The damage comes next: before sending the packet back to the attacker, the kernel reads the packet, trusting its new header size – copies 60 bytes, and more than half of that data comes from the neighboring memory.
“The next 32 bytes were not part of the packet's logical linear data,” the researcher explains in the detailed write-up.
This leads to “a repeatable, attacker-controlled host-memory disclosure,” exposing sensitive information that guests shouldn’t ever access.
The researcher claims that this issue isn’t read-only and can be further escalated – in their lab setup, turning it into controlled changes to kernel memory.
“Using host-memory observations and carefully controlled allocation behavior, we demonstrated selected 64-byte host-kernel writes,” the report reads.
The report doesn’t include the details of “what it took to move from the primitive to host control.” That is promised to be covered in Part 2.
A new class of vulnerability
It also appears that the exploit has been independently rediscovered by other security researchers.
Adel Ka, Detection & Response Lead at Perplexity AI, said they managed to rediscover the bug “in under 2 hours after seeing the Vercel bounty screenshot.”
A one-word hint was enough for the AI assistant to work its way – VirtIO. This is an open-standard communication protocol and paravirtualization framework for VM-host interaction.
Yibelo acknowledged that this became significantly easier once the discussions entered public mailing lists.
The researcher warns that this bug hints at other potential memory disclosure vulnerabilities.
“As far as we know, PwnEscape exposes an entirely new class of attacks in Linux networking: untrusted checksum metadata can rewrite security-sensitive packet fields after the kernel has already validated and acted on them, undermining assumptions across the networking stack far beyond the original VM escape,” the researcher concluded in their report.
A simple fix adds an additional guard in the kernel, checking that a checksum is never written to the packet’s IPv4 header and dropping malformed packets.
As previously reported, the bug was found through the Vercel Sandbox bounty program. The “modest” $50,000 bounty from a single Vendor sparked a debate over rewards for bugs that affect all major cloud providers.
The potential implications are massive – KVM code and the Linux kernel power many cloud platforms and other systems, creating a wide attack surface. A compromise of a single service or neglected workload can lead to complete control over the entire server and all the tenants and virtual machines running on it. However, no confirmed exploitation of the bug has been reported.