Guest VM Escape Flaw Found in Linux Kernel Networking Code
A newly disclosed critical vulnerability in the Linux kernel allows code running inside a virtual machine to read memory belonging to the physical host it runs on. The flaw, now tracked as CVE-2026-99999 and nicknamed PwnEscape, was discovered by security researcher Paulos Yibelo of pwn.ai during Vercel's $1 million Sandbox bug-bounty challenge, and was demonstrated live against Vercel's production cloud sandboxes before being responsibly disclosed. Vercel has confirmed the memory-leak behavior but says no customer files, secrets, or application data were ever read during the research. The bug carries a CVSS score of 9.3 (Critical) and sits in shared Linux networking code used by virtualization and container platforms industry-wide, not in any single vendor's configuration.
Incident Details
| Attribute | Value |
|---|---|
| CVE ID | CVE-2026-99999 |
| Nickname | PwnEscape |
| CVSS Score | 9.3 (Critical) |
| Component | Linux kernel networking / checksum handling (skb_checksum_help()) |
| Discoverer | Paulos Yibelo (pwn.ai) |
| Discovered via | Vercel's $1M Sandbox bug-bounty challenge (announced August 18, 2026) |
| Time to find | Approximately 3 days after the challenge opened |
| Disclosed | Privately, to Vercel and Linux kernel maintainers |
| In-the-wild exploitation | None observed |
| Patch status | Merged upstream; backported to multiple stable kernel branches |
How It Worked
The $1 Million Challenge
On August 18, 2026, Vercel opened a two-week, $1 million bug-bounty challenge inviting researchers to break the isolation boundary of Vercel Sandbox, the microVM-based environment the company uses to run untrusted and AI-generated code. The program ultimately drew 1,285 reports, paid out $242,000 across 57 valid findings, and surfaced exactly one Critical issue — the flaw that became PwnEscape. Yibelo, working from a standard sandbox with no special access, found it within roughly three days using an AI-assisted research workflow (internally called Omega-Pwn, built on a large-language model doing source-level analysis while a human researcher directed the work), reportedly at a token cost of under $700.
Root Cause: A Checksum Trust Inversion
The underlying bug is not in any hypervisor or in Vercel's configuration — it lives in core Linux networking code shared by KVM, Firecracker, and most other Linux-based virtualization stacks. When a network packet is marked CHECKSUM_PARTIAL, the kernel defers finishing the checksum calculation and later completes it via skb_checksum_help(), using metadata fields csum_start and csum_offset supplied with the packet to decide where to write the final checksum byte.
The flaw is that this metadata is not just descriptive — it authorizes a write into packet memory, and the kernel did not validate that the write location (csum_start + csum_offset) stayed within, or after, the IPv4 header it had already parsed and trusted. By crafting packets where the checksum write landed inside the header itself, Yibelo could flip the IPv4 IHL (header length) field from 0x45 (20 bytes) to 0x4f (60 bytes) — after the kernel had already validated the shorter, legitimate header. Later code then treated the packet as having a 60-byte header and reinterpreted the extra 40 bytes as IPv4 options.
From 32-Byte Leak to Lab-Only Host Takeover
Because the logical packet data was only 28 bytes (20-byte header plus an 8-byte payload), the kernel's IPv4 fragmentation code copied 32 bytes that fell outside the packet's real data — pure host kernel memory — into the fabricated "options" region, which then went out over the network inside the fragmented packet. A guest could repeat this indefinitely, harvesting roughly 32 bytes of host memory per packet sent.
Building on the same primitive, Yibelo showed two further effects, demonstrated only in his own lab environment built to mirror Vercel's setup, not against live production systems:
- Host crash: two specially crafted packets were enough to crash the host kernel and take down every sandbox running on it.
- Guest-to-host code execution: by steering the deferred write to attacker-controlled kernel allocations, the researcher achieved full administrator-level code execution on the host, escaping the VM boundary entirely. He reproduced this across four separate cold boots on hardware he owned and controlled.
Yibelo and Vercel were both explicit that the crash and code-execution results were lab findings, not a claim of code execution in any vendor's live production environment. Only the memory-leak primitive was demonstrated against a real Vercel sandbox, and Vercel states that review of the engagement found no instance of a researcher reading another customer's files, secrets, or application data.
Disclosure and the Fix
Yibelo reported the root cause to Linux kernel maintainers on September 4, 2026. Red Hat's Michael S. Tsirkin authored the accepted fix, merged upstream on October 8, 2026 (commit 6785011f8b16), which adds validation ensuring the checksum write location can never fall before the end of the already-parsed IPv4 header. The patch landed before skb_checksum_help() runs, enforcing a strict "validate first, then complete" ordering. Fixes have since been backported across stable kernel branches, including 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, and 6.18.57.
Vercel says it worked with AWS and other industry partners to coordinate notification and patching before any public write-up, "to make sure Vercel customers and other developers using the kernel were safe" while the CVE and patches were still under private review.
Impact Assessment
| Impact Area | Description |
|---|---|
| Confidentiality | Guest VM code could read up to ~32 bytes of host memory per crafted packet, repeatable indefinitely — a sustained information-disclosure channel across the guest/host trust boundary. |
| Availability | Two crafted packets could crash the host, taking down every tenant sandbox co-located on that host — a multi-tenant denial-of-service risk. |
| Integrity (lab-only) | Researcher achieved guest-to-host administrator code execution in a controlled lab environment, showing the primitive could theoretically escalate to full host compromise. |
| Scope | Affects shared Linux kernel networking code, not a single vendor — any KVM/Firecracker-based hypervisor, sandbox, or VPS platform running an unpatched kernel is potentially exposed. |
| Customer data | Vercel states no customer files, secrets, or application data were accessed during the research engagement. |
| Exploitation status | No evidence of in-the-wild exploitation; discovered and disclosed through a sanctioned bug-bounty program. |
Recommendations
For Cloud, VPS, and Sandbox Providers
- Patch immediately to the fixed kernel builds (5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, or later) or confirm your distribution has backported commit
6785011f8b16. - Audit multi-tenant isolation assumptions that rely solely on the hypervisor boundary — this bug demonstrates that shared kernel subsystems (networking, in this case) can undermine isolation even when the hypervisor itself is sound.
- Review nested-virtualization and Firecracker jailer configurations for defense-in-depth; Vercel notes its sandbox already layered additional hardening (disabled nested virtualization, jailer restrictions) beyond the kernel fix itself.
- Monitor for anomalous outbound fragmented IPv4 traffic from guest workloads as a detection signal while rolling out patches.
For Security Teams Running Self-Hosted KVM/Firecracker
- Treat this as a kernel-level advisory, not a cloud-vendor-specific one — any self-managed KVM, QEMU, or Firecracker deployment on an affected kernel version is exposed regardless of provider.
- Prioritize patching hosts that run untrusted or multi-tenant workloads (CI runners, code sandboxes, shared development environments) over single-tenant hosts.
- Re-run internal sandbox-escape and isolation testing after patching to confirm the fix is effective in your specific stack.
For Developers Using Cloud Sandboxes (e.g., Vercel Sandbox, AI code execution environments)
- No customer action is required for Vercel Sandbox users — the platform-level fix is Vercel's responsibility, and the company has confirmed no customer data exposure.
- As a general practice, avoid placing long-lived secrets inside ephemeral sandbox/VM environments used to execute untrusted or AI-generated code, regardless of provider.
Key Takeaways
- CVE-2026-99999 (PwnEscape) is a critical (CVSS 9.3) Linux kernel flaw in checksum-handling code (
skb_checksum_help()) that lets a guest VM leak host memory and, in lab conditions, crash the host or achieve host code execution. - The bug was found through Vercel's $1 million Sandbox bug-bounty challenge, which paid out $242,000 across 1,285 reports and surfaced this single Critical finding.
- The root cause is a trust-boundary failure in shared Linux kernel networking code, not a Vercel-specific misconfiguration — it potentially affects any KVM/Firecracker-based hypervisor or sandbox platform on an unpatched kernel.
- Only the 32-byte host-memory leak was demonstrated against live Vercel production sandboxes; the host-crash and code-execution results were lab-only, reproduced on researcher-owned hardware.
- Vercel confirmed no customer files, secrets, or application data were read during the engagement, and coordinated disclosure with AWS and other industry partners before the public write-up.
- A fix is merged upstream and backported across stable kernel branches — cloud providers, VPS hosts, and anyone self-managing KVM or Firecracker should patch immediately and verify multi-tenant isolation assumptions.