Pwnescape A Critical Linux Kernel Vulnerability

Pwnescape: A Critical Linux Kernel Vulnerability

On August 18, 2026, Vercel announced a $1 million challenge inviting researchers to break the isolation boundary of its Sandbox product. Vercel’s challenge explicitly invited researchers to attempt both network and host escape; we were interested in the latter. The question was simple: how much could an untrusted guest influence the host kernel without ever exploiting KVM itself? We took the challenge, put our research infrastructure to work, and within three days discovered a primitive buried in Linux networking that allowed guest-controlled checksum metadata to rewrite an IPv4 header after the kernel had already validated it. What initially looked like a 32-byte host-memory disclosure would eventually become a full guest-to-host escape in our own KVM and many other Hypervisor environments. The vulnerability wasn’t even in the hypervisor; it was in the Linux networking stack. This is the story of CVE-2026-99999, a Critical rated Linux kernel vulnerability leading to KVM escape. 🚀

Vercel later described it as the program’s most important report, and its final tally recorded just one Critical finding. That Critical was what is now PwnEscape. As far as we know, PwnEscape exposes an entirely new class of attacks in Linux networking: untrusted checksum metadata can rewrite security-sensitive packet fields after the kernel has already validated and acted on them, undermining assumptions across the networking stack far beyond the original VM escape. The vulnerable component is the host networking stack. “KVM escape” describes the guest/host security boundary crossed in our isolated proof, not the source file that contained the bug. Although the vulnerability originated in the Linux kernel and wasn’t a Vercel-specific flaw or misconfiguration, Vercel deserves tremendous credit for how they handled it. They moved quickly to protect their customers, launched their own independent research, identified and notified other affected hypervisor and sandbox providers, and worked closely with us to coordinate disclosure and fixes across the industry. Their efforts helped protect not just Vercel’s customers, but the wider ecosystem. 🌍

This research began with a broader hypothesis: the security of a sandbox depends on much more than its hypervisor. A guest interacts with an entire host operating system, including device emulation, virtual networking, packet filters, memory allocators, and the APIs that glue those pieces together. The particularly interesting question was: Can an asynchronous or deferred operation modify packet bytes after the kernel has already made security-relevant decisions about those same bytes? Linux checksum offload offered exactly that possibility. Linux does not always compute transport checksums immediately. Instead, it can carry a packet in a state where the checksum still needs to be completed. The critical point is that these values are not just descriptive metadata. They authorize a subsequent write into packet memory. If less-trusted software can influence them, their validity must survive every operation between admission and completion. This is the first trust failure: checksum metadata from a less-trusted origin crossed into host packet processing without being constrained against the header that later code would actually use. The accepted Linux fix is upstream as 6785011f8b16, ipv4: validate checksum_start before completing checksum. The guard therefore prevents this completion from writing into the IPv4 header.

To read the complete article see: Read full article