A newly patched Linux kernel bug lets code inside a virtual machine read host memory and, in a lab chain, take over the host. Researchers named it PwnEscape, and it carries the ID CVE-2026-99999 with a CVSS score of 9.3 (Critical).
The bug does not live in KVM, QEMU, or any single hypervisor. It sits in the Linux networking stack that processes guest traffic on the host, so any Linux host that runs untrusted VMs needs attention.
What Is PwnEscape (CVE-2026-99999) in the Linux Kernel?
PwnEscape is a guest-to-host escape bug in how the Linux kernel finishes delayed packet checksums.
Paulos Yibelo of pwn.ai found it during Vercel’s $1 million Sandbox security challenge, which opened on August 18, 2026. He reported the core primitive on the third day, working from a normal sandbox with no special access. Vercel rated it the most severe submission in the program and its only critical finding out of 1,285 reports. Vercel says it saw no evidence that anyone accessed customer data in its Sandbox product.
Key facts at a glance:
| Detail | Value |
|---|---|
| CVE ID | CVE-2026-99999 |
| Nickname | PwnEscape |
| Severity | CVSS 3.1 score 9.3, Critical |
| Component | Linux kernel IPv4 checksum offload path (skb_checksum_help) |
| Attack origin | Code running inside a guest VM |
| Privileges or user interaction | None required on the host side |
| Upstream fix | Commit 6785011f8b16, merged into mainline on October 14, 2026 |
How Does the PwnEscape VM Escape Work?
The attack abuses a performance shortcut that VMs rely on every second.
To save CPU time, a guest VM often sends packets without a finished checksum. It attaches metadata that tells the host kernel where to start the calculation and where to store the result. The host then completes the checksum later in processing.
PwnEscape breaks this in four steps:
- The guest sends a tiny crafted packet. In Yibelo’s demo, the packet totals 28 bytes, and a normal 20-byte IPv4 header takes up most of it.
- The host validates the header once. The kernel reads the header, treats it as 20 bytes, and moves on.
- The delayed checksum write lands inside the header. The attacker’s metadata points the write at the header length field, so the header now claims to be 60 bytes long.
- Fragmentation code trusts the new length. It copies 60 bytes of “header” from a 28-byte packet, which pulls 32 bytes of neighboring host memory into an outgoing packet that the guest receives.
Security folks call this a time-of-check/time-of-use (TOCTOU) bug. The kernel checks one version of the header and later acts on a different one. Unlike most TOCTOU bugs, this one needs no thread race, because the stale write happens during ordinary packet handling.
Can PwnEscape Give Attackers Root on the Host?
The 32-byte leak alone exposes data a guest should never see, but Yibelo pushed it much further in his lab.
On his own KVM and Firecracker test machines, configured to match Vercel’s setup, he combined repeated leaks with careful control over memory allocation. That gave him selected 64-byte writes into host kernel memory. He then ran a host-root helper and returned a host-generated marker to the guest, and the chain worked across four separate cold boots.
Where each result was proven:
- Memory reads: Reporting indicates the host-memory read worked against Vercel’s live sandboxes.
- Crashes and code execution: Yibelo tested these only on researcher-owned systems.
- Denial of service: Testing showed two packets could crash a host.
Is CVE-2026-99999 Being Exploited in the Wild?
No confirmed attacks exist so far, and CISA has not added the flaw to its Known Exploited Vulnerabilities catalog.
That status will likely change soon. Yibelo expects exploits for weaker configurations within weeks and exploits that work against default hypervisor setups in under a month. His write-up of the jump from the write primitive to full host control, promised as Part 2, will give attackers more to work with once it appears.
Which Linux Systems and Hypervisors Are Affected?
Any Linux host that runs guest VMs on an unpatched kernel falls in scope, with self-managed KVM hosts at the top of the list.
AWS says unpatched kernels from 4.4 through 6.18 can be affected when self-managed KVM hosts use virtio-net/TAP networking, including setups built on Firecracker. Reports suggest the underlying bug has existed in the kernel since around 2008.
Highest-risk environments:
- VPS and hosting providers with many tenants per host
- CI/CD runners and shared build systems
- Serverless and sandbox platforms, including AI agent sandboxes
- Malware detonation and research labs
- Developer environments that run untrusted code in VMs
What stays outside the immediate risk:
- AWS managed services. AWS states that Amazon EC2, AWS Lambda, and AWS Fargate are not affected.
- Non-Linux hypervisor hosts. VMware ESXi and Hyper-V hosts do not run this host-side Linux code, although Linux guests on them still carry the vulnerable kernel internally.
Which Linux Kernel Versions Fix CVE-2026-99999?
Fixes shipped for seven stable branches plus the 7.3 development series.
The patch entered the development tree on October 8 and reached mainline on October 14, 2026.
| Kernel branch | Vulnerable through | First fixed release |
|---|---|---|
| 5.10 | 5.10.271 | 5.10.272 |
| 5.15 | 5.15.222 | 5.15.223 |
| 6.1 | 6.1.189 | 6.1.190 |
| 6.6 | 6.6.158 | 6.6.159 |
| 6.12 | 6.12.112 | 6.12.113 |
| 6.18 | 6.18.56 | 6.18.57 |
| 7.2 | 7.2.10 | 7.2.11 |
| 7.3 (development) | Releases before 7.3-rc7 | 7.3-rc7 |
The patch checks that the checksum start never points inside the IPv4 header. When metadata fails that check, the kernel skips the write, and the guard covers several consumers, including IPv4 fragmentation. The kernel developers call it a defense-in-depth change and note that stricter validation of checksum metadata at packet input still needs work.
How to Patch the PwnEscape Linux Kernel Flaw
You must update and reboot the host kernel, because no workaround exists and guest updates do nothing here.
Step 1: Check Your Running Kernel
Run this command on every host that runs VMs:
uname -rCompare the result with the fixed releases above. Distributions often backport fixes to older version numbers, so also check your vendor’s advisory for CVE-2026-99999:
- Ubuntu Security Notices
- Red Hat Security Advisories
- Debian Security Tracker
- Amazon Linux Security Center
- SUSE Security Updates
Step 2: Install the Updated Kernel
On Ubuntu or Debian hosts:
sudo apt update && sudo apt upgradeOn RHEL, Fedora, or Amazon Linux hosts:
sudo dnf upgrade kernelStep 3: Reboot and Confirm
A new kernel only protects you once it runs. Migrate or stop guests, reboot the host, and run uname -r again to confirm the fixed build loaded. If you use Canonical Livepatch or kpatch, check whether your vendor published a live patch for this CVE before you skip the reboot.
Step 4: Prioritize Multi-Tenant Hosts
Patch shared hosts that run code from customers or strangers first, then move to internal-only virtualization. Where you can, stop placing new untrusted workloads on hosts that still run a vulnerable kernel, and turn off nested virtualization if you do not need it.
Step 5: Ask Your Providers
If you buy sandbox, CI, serverless, or VPS services, ask each provider in writing whether its hosts run a kernel fixed for CVE-2026-99999.
How to Detect PwnEscape Exploitation Attempts
A clean exploit leaves almost no trace on the host, so your best signal is the instability that failed attempts cause.
Look for these signs:
- Kernel
Oops,BUG, or general protection fault messages that mentionskb_,virtio_net, ortun_ - Segfaults or core dumps from
qemu-system,qemu-kvm, orfirecracker - A non-zero value in
/proc/sys/kernel/taintedon a host that started clean
This command pulls recent networking-related kernel crashes:
dmesg -T | grep -iE "BUG:|Oops:|general protection fault" | grep -iE "virtio|skb|napi|tun"If you find crash evidence on a host with tenant VMs, rotate secrets that lived in host memory, such as TLS private keys, SSH host keys, and cloud instance credentials. An empty result does not prove safety, so patching remains your main control.
How AI Found PwnEscape and What It Means for Patching
Yibelo used an AI-assisted research harness, and the speed of the find should change how fast you patch.
The setup surfaced the core primitive in about three days. Separately, a Perplexity AI security lead reportedly rediscovered the bug in under two hours from a one-word hint (VirtIO) after the bounty news spread. Yibelo also says public mailing list discussion made reproduction easier.
He calls PwnEscape the first of a new class of Linux networking attacks. Whenever untrusted checksum metadata can rewrite a packet field after the kernel validated it, later code may trust data that changed under it. Expect researchers to hunt for the same pattern in other protocols and code paths.
Frequently Asked Questions
Does updating the guest VM fix PwnEscape?
No. The vulnerable code runs on the host, so you must update and reboot the host kernel.
Am I affected if I only use AWS EC2 or Lambda?
AWS says its managed EC2, Lambda, and Fargate services are not affected. You need to act only if you run your own KVM hosts.
Does PwnEscape affect desktop Linux users?
The risk centers on hosts that run untrusted VMs. A desktop that runs only your own VMs faces far less exposure, but you should still install the kernel update when your distribution ships it.
Which hypervisors does PwnEscape affect?
The flaw sits in the Linux networking stack, not a specific hypervisor. KVM/QEMU and Firecracker setups that use virtio-net/TAP on Linux hosts carry the clearest exposure.
