PwnEscape Vulnerability: A Checksum Bug That Lets a Guest VM Read Host Memory

The PwnEscape vulnerability lets code running inside a virtual machine read memory from the host that carries it. Tracked as CVE-2026-99999, it sits in the Linux kernel’s networking code, and the fix only reached mainline on 14 October. If you run your own KVM hosts, this one is yours to patch.

What the PwnEscape vulnerability actually does

Researcher Paulos Yibelo of pwn.ai found it while hunting bugs in Vercel’s Sandbox challenge, which offered up to $1 million in rewards. Risky Bulletin reports that he collected $50,000, the top payout, and that his was the only report rated critical.

The flaw is not in KVM itself. It lives in how the kernel handles packet checksums. A guest can supply two pieces of checksum metadata, and the kernel checks them against one view of the packet. A later step then writes a checksum into a different spot. In the researcher’s words, “different parts of Linux were allowed to trust different versions of the same packet.”

How a checksum becomes a memory leak

According to the pwn.ai write-up, the deferred checksum write lands on top of the IPv4 header after the kernel has already validated it. The first byte flips from 0x45 to 0x4f. That tells the kernel the header is 60 bytes long instead of 20.

When the kernel then fragments the packet, it copies 60 bytes of header from a buffer that only holds 28 bytes of real data. The extra bytes go out on the wire as if they were IP options. Those bytes are host kernel memory, and the researcher reports 32 bytes leaking each time.

Thirty-two bytes sounds small. But an attacker can repeat the trick as often as they like, and what leaks is kernel memory the guest should never see.

How serious is it?

The scores disagree. CVE.org rates the flaw 9.3 (critical), while Red Hat gives it 8.8 and marks it important. The two differ only on whether the attacker needs privileges, and Red Hat calls its scores preliminary.

Beyond the leak, the researchers showed selected 64-byte writes into host kernel memory. They chained those into a helper that ran as root on the host. They did this on their own lab machines, and they say it is not a claim about any vendor’s production setup. A second post is due to cover the exploitation detail.

CSO Online notes that Yibelo expects working exploits for weaker configurations within weeks, and for default setups within a month. That is a forecast, not a confirmed attack. Vercel says no reports showed anyone accessing customer data in its Sandbox service.

Who should worry about the PwnEscape vulnerability

Most small firms do not run their own hypervisors. They rent virtual machines, and the provider patches the host. Even so, check. Some of you run KVM on a server in a cupboard, or host a few lab machines for developers. Those are the systems that quietly fall behind.

The risk grows when the guests are not fully trusted. Think of a shared build runner, a customer demo environment, or a VM that hosts third-party software. A single compromised guest on such a host is no longer contained.

Patching and what you can do now

The upstream fix is commit 6785011f8b16, which adds a check that the checksum start point sits after the IP header. Stable backports exist for the 5.10, 5.15, 6.1, 6.6, 6.12 and 6.18 branches, plus 7.2. The researcher calls it defence in depth rather than a redesign, so expect follow-up hardening.

There is no configuration workaround. Red Hat says no mitigation meets its criteria, and the write-up offers none. So the job is simple: find every Linux host that runs guest workloads, check whether your distribution has shipped the backport, and schedule the reboot.

• List hosts that run KVM, including build servers and lab boxes nobody remembers.
• Check your vendor’s advisory for CVE-2026-99999 and confirm the running kernel, not just the installed package.
• Prioritise hosts where guests are less trusted: shared tenants, CI runners, customer sandboxes.
• Ask your cloud provider in writing whether managed services are affected.

Why this belongs in your test scope

This follows a run of guest escapes. We covered an earlier KVM escape and the VMware flaws before it. The pattern is clear: isolation between guests is a promise, and promises need checking.

A good penetration test asks what an attacker can reach once they hold a single guest. If the answer is “the host and every neighbour”, patch cadence and network segmentation matter far more than the guest’s own hardening. If you want that question tested against your own environment, get in touch.