A security researcher disclosed a critical Linux kernel vulnerability that lets an untrusted virtual machine read host memory, crash the host, and run code on it, breaking the isolation boundary that separates tenants on nearly every major cloud.
The flaw, tracked as CVE-2026-99999 and nicknamed PwnEscape, lies in the Linux networking stack rather than in any hypervisor, which makes it dangerous at scale.
The vulnerability was disclosed by Paulos Yibelo during Vercel’s $1 million Sandbox challenge, working from an ordinary sandbox with no special access, and was the only Critical finding among the 1,285 reports the two-week program drew. Vercel paid out $242,000 in bounties and called the kernel defect its most important report.
The bug lives in how Linux handles checksum offload, a performance feature that lets the kernel defer computing a packet’s checksum until later. A packet can carry metadata — csum_start and csum_offset — that tells the kernel where to write the finished checksum once it is ready. Those values are not just a description of the packet; they authorise a write to the packet’s memory, and a guest can influence them.
The attack turns that deferred write against the packet’s own IPv4 header. The kernel parses and validates the header early, treating it as a normal 20-byte header, and makes routing and fragmentation decisions based on that.
Later, during output fragmentation, the pending checksum write fires and overwrites the first byte of the header, flipping the header-length field from 0x45 to 0x4f — from 20 bytes to 60. Nothing re-checks the header after it changes.
When the fragmenter then reads the header as 60 bytes long, it copies 32 bytes of adjacent host memory that were never part of the sender’s packet and emits them on the wire as if they were IP options. The researchers describe it as a time-of-check/time-of-use problem in which the “time” between validation and use is just the normal sequence of networking operations, with an attacker-influenced write slipped in between. Different parts of the kernel, in effect, trusted different versions of the same packet.
A repeatable, attacker-controlled read of host memory is already serious on shared infrastructure, but pwn.ai took it further on its own hardware. Using the leak to map host memory and controlling allocation behaviour, the team demonstrated selected 64-byte kernel writes and chained them to execute a host-root helper, completing a full guest-to-host escape across four separate cold boots.
The host-memory leak was also demonstrated against Vercel’s production sandboxes; the crash and code-execution steps were proven on the researcher’s own KVM and Firecracker machines configured to match.
“Different parts of Linux were allowed to trust different versions of the same packet,” the researchers wrote.
Because almost every major cloud provider isolates customer workloads on this same kernel layer, Vercel treated the defect as a shared-infrastructure risk and worked with AWS and other partners to coordinate a fix before disclosure. The researchers reported the root cause privately to the kernel security team on September 4, and Red Hat’s Michael S. Tsirkin reproduced it three days later.
The accepted upstream fix, commit 6785011f8b16, adds a small helper, ip_check_csum_start(), in include/net/ip.h and calls it before the checksum is completed in each of five affected consumers, including IPv4 output fragmentation, bridge fragmentation and the netfilter and XFRM paths. The guard rejects any packet whose checksum would fall within the IPv4 header, enforcing the invariant that the write must occur at or beyond the end of the parsed header. The commit message calls it a defence-in-depth measure and notes that broader validation of untrusted checksum metadata still needs work.
The patch was applied to the net.git tree on October 8 and merged into Linus Torvald’s mainline tree on October 14. The vulnerability was confirmed on Linux 6.12 and 7.x hosts in testing; stable backports and the official CVE publication were still being coordinated at the time of disclosure, and administrators should track the live kernel records for the fixed build numbers for each supported series.
Community Discussion
Join the conversation. Ask questions, share solutions, and help others.
Be the first to start the discussion!
