PwnEscape: Linux Flaw Lets Attackers Escape a KVM VM

PwnEscape (CVE-2026-99999) is a critical flaw discovered in the Linux kernel that, in a lab environment, made it possible to escape a KVM VM. Here’s what you need to know about this vulnerability.

It all started with a challenge launched on August 18, 2026 by Vercel: one million dollars in bounties for anyone who could break out of Vercel Sandbox, its service that runs customer code inside micro-VMs. By the third day, Paulos Yibelo, a researcher at pwn.ai, submitted a report... but it didn’t really concern Vercel. The flaw is in the Linux kernel network stack, a layer that almost all major cloud providers rely on to isolate their customers.

So even though no one broke out of Vercel Sandbox, this researcher’s discovery is far from trivial. In fact, in the post-event recap published on October 14, Vercel says it was the most important report tied to the challenge: it was also the only critical vulnerability out of 1,285 submissions. For its part, Ubuntu assigns it a CVSS 3.1 score of 9.3 out of 10.

To exploit this vulnerability, tracked as CVE-2026-99999, an attacker must be able to run code inside a VM. But that’s hardly a barrier, since that’s exactly what cloud platforms, CI/CD services, and AI agent sandboxes already do. In some cases, running untrusted code is literally their job.

A checksum write that rewrites the IPv4 header

For performance reasons, Linux can defer the calculation of a network packet checksum. In that case, the packet travels in the CHECKSUM_PARTIAL state, with two metadata fields, csum_start and csum_offset, which indicate where the calculation begins and where the result should be written. The problem is that these metadata fields can be supplied by the guest VM.

The pwn.ai technical report also provides more detail about the sequence involved. The host parses a standard 20-byte IPv4 header, then skb_checksum_help() completes the checksum just before fragmentation. With malformed metadata, that write lands in the already validated IPv4 header: the first byte changes from 0x45 to 0x4f, and the IHL field now advertises a 60-byte header.

When it is time to fragment the packet, ip_do_fragment() therefore believes the header is 60 bytes long, even though the packet only contains 28 bytes of valid data. To fill the gap, the kernel reads further into its own memory. Those 32 bytes, which do not belong to the packet, are copied into the header as IP options and sent over the network, where the attacker can simply retrieve them.

In short, the kernel validates the packet, then allows it to be modified at the guest’s request, and then trusts that modified version. "Different parts of Linux were allowed to trust different versions of the same packet," the researchers explain.

By exploiting this flaw, nicknamed PwnEscape, the researchers were able to reach root code execution on the host, though not consistently. Here are the three demonstrations they carried out:

• Host memory leak: demonstrated on Vercel’s production sandboxes, continuously as long as the guest sends packets.
• Host crash: according to Vercel, two packets are enough on the researcher’s KVM and Firecracker machines configured like Vercel’s.
• Root code execution on the host: pwn.ai says it obtained targeted 64-byte writes in kernel memory, then executed a root command on the host, across four cold boots. Again, only on its own machines.

The fix applies to the host kernel

The security fix was integrated in commit 6785011f8b16, signed by Michael S. Tsirkin (Red Hat). To counter this security flaw, the behavior was adjusted: before calculating the checksum, the kernel checks that it cannot overwrite the IPv4 header. If it can, the packet is rejected. Integrated into the Linux kernel on October 14, 2026, this protection is only a first step: filtering malformed packets as soon as they arrive still requires more work.

The first fixed stable releases are said to be 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, and 7.2.11. Debian has already responded for Debian 13 Trixie: advisory DSA-6568-1 delivers kernel 6.12.113, according to Debian’s tracker. On the other hand, Debian 12 Bookworm remains vulnerable as of this writing. Ubuntu still says its kernels are under evaluation.

Finally, an important reminder: it is the host kernel that must be updated first, not the kernels inside the VMs.

Florian Burnel Co-founder of IT-Connect

Systems and network engineer, co-founder of IT-Connect and Microsoft MVP "Cloud and Datacenter Management". I'd like to share my experience and discoveries through my articles. I'm a generalist with a particular interest in Microsoft solutions and scripting. Enjoy your reading.

See Full Bio