PwnEscape lets a guest VM read its host’s memory with forged network packets
On October 15, 2026, a critical Linux kernel flaw, CVE-2026-99999 nicknamed PwnEscape, lets code running inside a virtual machine read its host’s memory, crash the host, or execute code on it. Update the host kernel, not the guest kernel, and verify the fix with your distribution.
August 2026. Vercel runs a security challenge offering up to $1 million to anyone who can break out of its sandboxes. October 15, 2026. The winning flaw — CVE-2026-99999, nicknamed PwnEscape — goes public: code inside a virtual machine can read its host’s memory. 9.3 out of 10. That is the CVSS score assigned by the kernel maintainers. Why it matters: the flaw is not in any single cloud’s code, but in the Linux kernel’s networking layer — the shared foundation almost every cloud provider uses to keep its customers’ workloads apart.
A flaw in the layer every cloud shares
PwnEscape was found by Paulos Yibelo of pwn.ai during a Vercel security challenge and reported privately before any public release. No sign of real-world exploitation has been observed. But the flaw’s location is what makes it structurally serious: it lives in the Linux kernel’s networking code, specifically in the checksum handling of IPv4 packets. It is not a Vercel misconfiguration, and it is not a Firecracker bug — Firecracker being the small virtual machine that isolates workloads at Vercel. It is the kernel the host runs, the very layer nearly every large cloud uses to separate customer workloads.
Concretely, Vercel Sandbox runs each customer’s code in its own Firecracker microVM on bare-metal Amazon EC2 hosts. That microVM is the wall between one customer and the host, and between one customer and another. The flaw is not in that wall: it is in the Linux kernel the host runs. pwn.ai notes that Vercel’s sandbox was already hardened beyond normal industry standards, with no misconfiguration it could find. Vercel’s conclusion is blunt: a flaw in that location threatens shared infrastructure generally, not any one provider.
What the researcher demonstrated
The demonstration covers three effects, all from the same kernel flaw. First, host memory read: each forged packet sent from the guest could carry back roughly 32 bytes of host memory, and the guest could keep going as long as it kept sending packets. Vercel confirmed the leak against its production sandboxes.
Second, host crash: two specially crafted packets were enough to take down a host and every sandbox running on it. Third, code execution on the host: using the same flaw, the researcher reached administrator control of a host, breaking out of the virtual machine. Those last two effects were observed only on the researcher’s own machines, set up to match Vercel’s environment — a lab result, “not a claim of root command execution in any vendor’s production environment,” he stresses.
One detail stands out about the method. pwn.ai says it found the flaw in three days with an AI-assisted research system — the model GPT-5.6 Sol doing the source-code analysis while humans directed and validated — for a cost of under $700 in API tokens. It is one more case study, after a team reached internal systems at OpenAI earlier this year, of a large language model being used to discover and chain real flaws.
Critical severity, but a local attack vector
The CVE record publishes a score of 9.3 (Critical), with a “local” attack vector. In plain terms: the attacker must already be running code inside a guest, as the researcher was. This is not a flaw an outsider can trigger by sending packets across the open internet. The NVD had received the entry but had not finished its own review at publication time, and the flaw is not in CISA’s KEV catalog.
That “local” qualifier should not reassure. In a multi-tenant cloud model, the entry barrier is not the internet: it is any customer renting a virtual machine on the same host, or any attacker who has already compromised a single guest. Host-memory leakage, even 32 bytes per packet, is a continuous exfiltration channel that can eventually reveal other tenants’ secrets, keys, or host credentials. This is exactly the scenario virtualization is supposed to make impossible.
The fix, and what it actually fixes
The fix is a single kernel change, commit 6785011f8b16, written by Michael S. Tsirkin of Red Hat and merged into mainline. It adds a check that a packet’s checksum data cannot point into the IPv4 header before the kernel acts on it, and applies that check at five places in the networking code.
The change is deliberately partial. Its author calls it “a defence in depth measure” and notes that a fuller check at the point where packets enter the kernel still needs work. The maintainers backported the fix to the stable branches. Per the CVE record, these are the first fixed versions in each branch:
- 5.10 → 5.10.272
- 5.15 → 5.15.223
- 6.1 → 6.1.190
- 6.6 → 6.6.159
- 6.12 → 6.12.113
- 6.18 → 6.18.57
- 7.2 → 7.2.11
Distributions ship their own kernels and often fold in this kind of fix without changing the version number. Check your distribution’s advisory and confirm the fix is actually in the kernel the host is running, not just the number returned by uname.
What to do
The rule is simple and often misapplied: you patch the host kernel, not the guest kernel. Updating only a guest’s kernel does not fix the host. Move the host to one of the fixed versions above, or to the vendor build that includes the fix, then reboot into it. The sources give no separate workaround if you cannot update yet.
# The host kernel actually running, not a container or guest kernel:
uname -r
# On Debian/Ubuntu: list the installed host kernel packages
dpkg -l 'linux-image-*' | grep '^ii'
# Compare against the first fixed version of the relevant branchWhere patching has to wait, the usual defense is to limit what a breakout could reach. Vercel keeps its host kernels up to date, disables nested virtualization, and runs each microVM under Firecracker’s jailer, which grants the microVM process only the permissions it strictly needs. That does not fix the flaw, but it narrows what an attacker who exploited it could do. For a private-cloud operator or hosting provider, that is the hardening level to aim for until the fix is deployed everywhere.
One wider implication follows from how the flaw was found. A team reached a critical kernel bug in three days, for less than $700 in tokens, by pairing a reasoning model with directed human oversight. That cuts both ways: it is good news for defenders who want to audit the shared kernel layer before attackers do, and a warning that the same leverage is available to anyone renting a VM on your host. The economics of finding escape flaws just changed, and the patch cycle has to keep up.
Verdict
If you run multi-tenant virtual machines — hosting, private cloud, shared build or test environments — treat PwnEscape as a patching emergency: the flaw breaks the isolation that is the entire point of your infrastructure, and the fix is a single host kernel change. If you only run single-tenant VMs whose guests are all trusted, the risk is low, but apply the fix at the next cycle anyway: it is already in the stable branches, and defence in depth is only a reboot away. In every case, the lesson outlives this CVE: the kernel’s networking layer is the shared foundation of the entire cloud industry, and a single flaw there earns — as here — a critical score that owes nothing to any provider’s negligence.