PwnEscape (CVE-2026-99999): A Linux IPv4 Stack Bug Lets a VM Escape to Its Host

For years, the deal behind every cloud server has been simple: whatever runs inside your virtual machine stays inside your virtual machine. A newly disclosed Linux kernel flaw nicknamed PwnEscape breaks that promise in a way that should get every hypervisor admin's attention. Using nothing more than carefully crafted network packets, code running inside a guest VM could read the host's memory, crash the host, and in a lab setting take full administrator control of it.

The bug is tracked as CVE-2026-99999. The Linux kernel CVE Numbering Authority (CNA), which assigned it, rates it 9.3 out of 10, or Critical, in the CVE record on cve.org. That score comes from the kernel CNA, not from NVD. As of October 19, the U.S. National Vulnerability Database lists the entry as "Received" and has not published its own score, and CISA's SSVC assessment in the NVD entry records exploitation as "none."

PwnEscape came out of a two-week challenge Vercel ran in August, inviting researchers to break out of Vercel Sandbox for up to $1 million in total rewards. According to Vercel's write-up of the results, the company received 1,285 reports and paid $242,000 in bounties. The single most important report arrived on day three from Paulos Yibelo of the security firm pwn.ai, who was working from a standard sandbox with no special access.

Vercel says the host memory leak was demonstrated against its production sandboxes. The crash and code execution attacks were shown on the researcher's own KVM and Firecracker machines, configured to match Vercel's setup. Vercel also says no report in the challenge showed anyone accessing customer data. pwn.ai has published a detailed technical write-up, also posted to the oss-security mailing list, and told The Hacker News that the work was done with an AI-assisted research setup, with human researchers directing it and checking the results on systems they controlled.

The flaw lives in an unglamorous corner of the kernel: checksum offloading. To save CPU time, a network packet can arrive with a note that effectively says "the checksum still needs to be filled in, starting at this offset." The kernel fills it in later, just before the packet leaves.

The problem, as described in the CVE record and pwn.ai's analysis, is that a malicious guest gets to choose that offset. A microVM hands the host a packet through its virtual network card, and the host passes it into its own IPv4 stack. The kernel checks the IPv4 header, makes decisions based on it, and only afterward completes the checksum. If the guest pointed the checksum offset into the IPv4 header itself, that late write quietly changes a header the kernel already trusted, including the field that says how long the header is.

When the host then fragments the packet, it believes the new, bigger header length and copies bytes from beyond the real packet into the outgoing fragments. That is the leak. According to The Hacker News, each packet could carry back roughly 32 bytes of host memory, and the guest could keep it going for as long as it kept sending. The same kind of corruption, pushed further, produced the crash and the code execution results.

pwn.ai calls this "an entirely new class of attacks in Linux networking," and that is a big part of why this one stands out. It is not a bug in Firecracker or in Vercel's configuration. pwn.ai said it found no misconfiguration in Vercel's sandbox at all. The weakness sits in the host kernel's networking code, which is the shared layer nearly every cloud uses to keep tenants apart. Despite the "KVM escape" label it picked up on the oss-security list, the bug is not in KVM or the hypervisor either. The CVE record places it in the host\'s IPv4 stack: guest packets written to the host TAP device are handed by tun_get_user() to IPv4, and when ip_do_fragment() calls skb_checksum_help(), the checksum write lands in an IPv4 header that was already routed and validated. Guests are simply the easiest way to feed that path packets with bad checksum metadata. As Vercel put it, "almost every major cloud provider isolates customer workloads on this same layer of the Linux kernel, so any defect is shared-infrastructure risk."

The CVE record lists the affected range as starting with Linux 2.6.27, which dates back to 2008.

The record scores the attack vector as local. That matters. Someone on the open internet cannot trigger PwnEscape by throwing packets at your server. The attacker needs to be running code inside a guest that sends traffic through a virtual network device the host processes. The record's own scenario describes a malicious microVM whose packets flow through the host's TAP interface, and it notes the attacker needs no host credentials and no action from a host administrator or anyone else.

In practice, that puts the following at the front of the line:

• Cloud and hosting providers, plus anyone selling VMs or sandboxes to strangers, since untrusted code inside a guest is the whole business model.
• KVM and Firecracker hosts in general, including the platforms that run AI agents and code in disposable microVMs.
• Proxmox VE and other KVM-based virtualization clusters, especially where different teams, customers, or students share the same hosts.

A small home lab running only your own VMs faces much lower real-world risk, but the fix is the same, and it is not worth skipping. PwnEscape is not on CISA's Known Exploited Vulnerabilities (KEV) list, and there is no evidence of attacks in the wild. A public proof of concept for the memory-leak part exists, but no full escape exploit has been published. The proof of concept, posted on GitHub on October 17, exercises the host-memory disclosure step on a prepared lab interface; its author says it reproduces on kernel 6.18.54 and that 6.18.57 fixes it. Turning that leak into a working escape is the harder step, and pwn.ai does not expect it to stay out of reach for long: in its write-up, pwn.ai says it expects "exploits in weaker configurations to arrive in weeks, and exploits working in default hypervisor configurations to arrive in under a month."

The upstream fix is a single commit, 6785011f8b16, "ipv4: validate checksum_start before completing checksum," by Red Hat's Michael S. Tsirkin. It adds a check that the checksum start cannot point inside the IPv4 header, and puts that check in front of checksum completion in five places, including IP fragmentation, netfilter's NFQUEUE and CHECKSUM paths, bridge conntrack, and IPsec output. The commit message is candid that this is "a defence in depth measure" and that "a more complete validation at input is forthcoming, but needs more work."

The fix has been backported to the stable kernels, as LWN's stable kernel coverage notes. According to the CVE record, these are the first fixed versions in each branch: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, and 7.2.11, with mainline fixed as of 7.3-rc7.

Distributions have started shipping it. As of October 19:

Proxmox's advisory, dated October 16, says incomplete validation of checksum metadata "allowed an attacker to read host memory and write host kernel memory via the virtio network stack, allowing an escape from inside a KVM guest." Fedora's 7.2.11 builds sit in the F43, F44 and F45 updates repositories, matching the upstream 7.2.11 fix.

Here is the part that is easy to miss. Installing a patched kernel package does nothing until the host actually boots into it. Until every host is rebooted onto the fixed kernel, a guest running on it can still read that host's memory. Updating the kernel inside a guest does not protect the host either. If you can, live-migrate VMs off each node, reboot it onto the new kernel, confirm, and move on to the next. The sources offer no standalone workaround for the flaw itself.

For Proxmox VE 9, Proxmox's 7.0.14-24 kernel (Oct 9) includes fixes matching the upstream patch, according to the pve-kernel changelog. An earlier build, 7.0.14-22 (Oct 6), had already blocked the guest-to-host path by dropping guest packets whose checksum start points into the IP header when the host needs to fragment them. To patch a Proxmox VE 9 host, run apt update && apt full-upgrade, reboot the host, and then check that uname -r shows 7.0.14-24-pve or newer. Patching the host is what matters here; updating the guests does not fix it.

Proxmox VE 8 users should not wait for a 6.8 kernel fix. According to the Proxmox VE FAQ, PVE 8 reached end of life in August 2026, and Proxmox's PSA-2026-00068-1 lists only the PVE 9 kernel, 7.0.14-24, as fixed. The way out is to upgrade to PVE 9, following Proxmox's 8 to 9 upgrade guide, and to use the hardening steps below only as a stopgap until that is done.

Are you affected?

• Do you run untrusted or shared guests on Linux KVM or Firecracker hosts? That is the exposed case. Every kernel from 2.6.27 up to the fixed releases is in the affected range.
• Still on Proxmox VE 8? PVE 8 is past end of life and its 6.8 kernel is not listed as fixed. Upgrade to PVE 9. Until then, as a stopgap, limit untrusted guests on those hosts and keep nested virtualization off.

Patch and reboot. On Proxmox VE 9 or Debian:

apt update && apt full-upgrade
reboot

Then run uname -r again to confirm the new kernel is running.

Fedora and other dnf-based systems: ask the package manager directly.

sudo dnf updateinfo list --cve CVE-2026-99999
sudo dnf needs-restarting -r

Debian: check the installed kernel package against the table above, and whether a reboot is pending:

dpkg -l 'linux-image*' | grep ^ii
sudo needrestart -k

Proxmox VE: confirm the installed and booted kernel.

pveversion -v | grep proxmox-kernel
proxmox-boot-tool kernel list

PVE 9 hosts need 7.0.14-24-pve or newer, booted.

Check the running kernel on each host, not the guests:

uname -r

Start on each host, not inside the guests. Run uname -r to see which kernel is actually running, and compare it with the kernel you most recently installed. If they differ, the host is waiting on a reboot and is still exposed.

Do not lean on the version number alone. Distributions routinely backport fixes into their own kernel builds without matching the upstream version, as The Hacker News also points out. Check your distribution's security tracker or changelog for CVE-2026-99999, or for the "validate checksum_start" change, and confirm that the specific build you are running includes it. On Proxmox VE 9, that means confirming each node is booted into 7.0.14-24-pve or newer.

While you wait for a maintenance window, reduce what a successful escape could reach. Vercel says it keeps host kernels current, disables nested virtualization, and runs each microVM under Firecracker's jailer, which limits the VMM process to only the permissions it needs. None of that fixes PwnEscape, but it narrows the damage if someone gets there first.

PwnEscape is also a reminder of how quickly bug hunting is changing. pwn.ai says it found the flaw in about three days with an AI-assisted system, at a cost of under $700 in API usage, according to The Hacker News. If finding kernel bugs keeps getting faster and cheaper, the time between a fix landing and someone weaponizing it will keep shrinking too. For anyone running shared virtualization, the safest assumption is simple: patch the host, reboot the host, and do not let the reboot wait.