Vulnerabilities

PwnEscape: a guest VM can reach into its Linux host

By Yaali. October 20, 2026, 6 min read, Vulnerabilities, Patching, Cloud.

CVE-2026-99999 lets code in a KVM guest leak host memory and crash the host through Linux networking. Who is exposed, fixed kernels and how to check.

A flaw in the Linux kernel's IPv4 networking code lets a program inside a virtual machine read memory from the host it runs on, and crash that host. Named PwnEscape and tracked as CVE-2026-99999, it carries a CVSS 3.1 score of 9.3 from the kernel's own CVE team; Red Hat scores it 8.8. The fix reached the mainline kernel on October 14 and seven stable branches the next day, but several big distributions had not shipped a kernel with it by October 20.

You are exposed if you run KVM hosts (Proxmox, libvirt, Firecracker and similar) that give untrusted code a guest with virtio-net networking over TAP or vhost-net, on a Linux kernel from 4.4 through 6.18 without the fix. That covers hosting providers, CI runners, AI agent sandboxes and multi-tenant labs. AWS says EC2, Lambda and Fargate are not affected, but a KVM host you run yourself, including one inside an EC2 instance, is.

How it works

To save CPU, a guest's virtual network card can hand checksum work to the host. The guest marks a packet as CHECKSUM_PARTIAL and supplies two numbers: csum_start, where the checksum calculation begins, and csum_offset, where the result gets written. The host fills in the checksum later, just before the packet leaves.

The host parses and validates the standard 20-byte IPv4 header first. The trouble is that the guest controls csum_start, and nothing checked that it pointed past the end of that header. When the host later completes the checksum in skb_checksum_help(), it writes the result into the already validated header. In the researcher's example the first header byte changes from 0x45 to 0x4f, so the header length field now claims 60 bytes instead of 20.

The packet then hits fragmentation in ip_do_fragment(), which reads the header length again and trusts it. The packet only holds 28 bytes of real data, so the kernel reads 32 bytes of its own memory beyond the packet, copies them into the header as IP options, and sends them out on the network where the attacker can collect them. This is a time-of-check to time-of-use (TOCTOU) bug: the header is checked once and used later after it has changed, with no race between threads needed. The researcher summed it up as different parts of Linux trusting different versions of the same packet.

The score from the kernel's CVE Numbering Authority (CNA) assumes no host credentials at all; AWS assumes the attacker has privileged access inside the guest, which anyone renting a VM or running code in a sandbox usually has. The flaw is in host networking, not in KVM or QEMU, and it cannot be triggered from the internet: physical network cards do not set this checksum metadata from received data. Red Hat also says a local user can trigger it on the host itself, so ordinary Linux servers need the update too, just less urgently.

What attackers are doing

Paulos Yibelo of pwn.ai found the bug while working on Vercel's $1 million Sandbox challenge, announced on August 18. He reported the root cause to the kernel maintainers on September 4, and Michael S. Tsirkin of Red Hat reproduced it around September 7. The fix, commit 6785011f8b16, was taken into the networking tree on October 8, merged on October 14, and the CVE was published on October 15.

What has been shown so far is split by environment:

• A repeatable leak of host memory against Vercel's live production sandboxes.
• Host crashes on the researcher's own KVM and Firecracker machines, set up like Vercel's.
• Controlled 64-byte writes into host kernel memory and a command run as root on the host, again only in the researcher's lab, in four cold-boot runs. This chain has not been published.

Vercel says it found no evidence that anyone accessed customer data in Vercel Sandbox. No exploit code is public and no attacks in the wild have been reported. The researcher expects working exploits for weaker configurations within weeks and for default hypervisor configurations within about a month, so treat the quiet period as short.

What to do

Patch the host kernel first. Guest kernels are not the priority, because the bug fires in the host while it handles the guest's packets.

1. Find the hosts that matter. On each Linux server, lsmod | grep -E "kvm|vhost_net|tun" shows whether it hosts VMs, and virsh -c qemu:///system list --all (or qm list on Proxmox) lists the guests. Put hosts that run code you do not control at the top of the list.
2. Install a fixed kernel and reboot. Upstream fixed releases are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 and 7.2.11. Distribution kernels use their own numbering and backport fixes, so compare against your vendor's advisory, not against uname -r alone.
   • Debian 12: linux 6.1.190-1 (DLA-4841-1). Debian 13: linux 6.12.113-1 (DSA-6568-1).
   • Amazon Linux 2023: kernel-6.1.188-233.385.amzn2023 or kernel6.12-6.12.110-135.201.amzn2023 and later; AWS bulletin 2026-137-AWS lists the rest.
   • Proxmox VE: proxmox-kernel-7.0.14-24-pve or later.
   • AlmaLinux 8, 9 and 10: fixed kernels are in the almalinux-testing repository (for example kernel-5.14.0-687.57.2.el9_8 on AlmaLinux 9).
   • Red Hat Enterprise Linux, Rocky Linux, Ubuntu and SUSE: no fixed package confirmed as of October 20. Watch their CVE pages.
3. Reboot, then verify. An installed kernel does nothing until the host boots into it. Live-migrate or shut down guests, reboot one host at a time, then confirm uname -r matches the fixed package. On RPM systems, dnf --refresh updateinfo info --all --cve=CVE-2026-99999 shows whether an advisory covers you.
4. If you cannot patch yet. AWS, Red Hat and AlmaLinux say there is no workaround. Rebootless patches exist from some providers, including TuxCare KernelCare for several Enterprise Linux 9 and 10 builds; confirm the patch names this CVE for your exact running kernel. Turning off checksum offload on untrusted guests' virtio-net devices has been suggested, but it is untested, costs throughput and is not a fix. The safest interim step is to move untrusted workloads off unpatched hosts.

Checking for past abuse is hard. The leak travels inside outgoing packets that look normal, and no indicators of compromise have been published. A host that has crashed without explanation while running untrusted guests is worth a closer look, but a clean log does not prove anything. If you ran hostile code on an unpatched host, assume anything in host memory could have been read, and rotate secrets the host held, such as storage keys, API tokens and management credentials.

Multi-tenant hosts need a different patch clock

Most teams patch hypervisors on a slow cycle because every reboot means migrating guests. That habit assumes the guests are friendly. If your platform runs customer code, pull requests from strangers or AI agents, then each guest is an attacker with a local foothold, and a guest-to-host bug deserves the same speed as an internet-facing remote code execution flaw. Keep spare capacity so hosts can be drained and rebooted within a day, and keep untrusted and trusted workloads on separate hosts so one bug does not expose both.

If you run your own virtualisation platform and want help sorting exposed hosts or planning rolling reboots, our cloud and Kubernetes security and platform and cloud engineering teams do this work. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would handle it.

Sources: IT-Connect, CSO Online, AWS security bulletin 2026-137-AWS, TuxCare, VirtFusion, AlmaLinux, Hardware Busters, SmartScope.