PwnEscape (CVE-2026-99999): The Critical Linux Kernel Flaw That Breaks VM Isolation

Cloud computing depends on one boundary – the isolation between a guest virtual machine and the host underneath it. For over a decade, hypervisors and microVM architectures have kept multi-tenant workloads apart, so code running in a customer’s environment cannot touch the bare-metal infrastructure hosting it. This week’s disclosure of PwnEscape (CVE-2026-99999) broke that assumption. The flaw sits not in a hypervisor’s emulated device but in the mainline Linux kernel’s networking stack.

Rated 9.3 (Critical) on the CVSS scale, PwnEscape lets an attacker with ordinary code-execution privileges inside a guest VM read arbitrary host kernel memory, crash the physical host, and, in a lab setting, escape to the host with root privileges. Security researcher Paulos Yibelo of pwn.ai found it during Vercel’s $1 million Sandbox security challenge. The flaw exploits a “trust inversion” in how the Linux kernel handles deferred network checksums. The vulnerable code path is in the shared IPv4 networking stack that nearly every major cloud provider uses to route guest traffic, so the threat reaches beyond any single platform or hypervisor.

This article covers how the bug works, how an AI-assisted workflow found it, and what administrators need to patch.

The $1 million Vercel Sandbox challenge and the AI-assisted discovery

On August 18, 2026, cloud deployment platform Vercel launched a two-week public bug bounty program on HackerOne, offering up to $1 million in total payouts to researchers who could breach the isolation boundary of its Vercel Sandbox product. The sandbox runs untrusted, user-generated code and AI agent workloads. It relies on Firecracker microVMs, the open-source virtualization technology AWS originally developed, which gives hardware-level virtualization with the startup speed of containers. Each customer workload runs in its own microVM with its own guest kernel, on a bare-metal Amazon EC2 host.

The challenge had two goals: bypass the sandbox’s network restrictions, and execute a full VM escape to compromise the underlying host. It drew 1,285 vulnerability reports over the two weeks and $242,000 in total bounty payouts. The most consequential report arrived on day three.

Yibelo, working from a standard sandbox environment with no special privileges, found a logic defect in the host’s Linux kernel networking stack. He found it with an experimental AI-assisted research harness called Omega-Pwn, which combined pwn.ai’s proprietary tooling with elements of SingularityNET’s OmegaClaw architecture. GPT-5.6 Sol, a large language model, served as the main reasoning engine. It analyzed millions of lines of Linux kernel source, traced the lifecycle of network packets, and hypothesized edge-case state mutations.

The model did the heavy lifting of source analysis and data-flow tracing. Human researchers directed the investigation, challenged the model’s hypotheses, and validated the most promising vectors against live kernel behavior in controlled environments. Together they found a critical zero-day VM escape in three days, at an estimated API compute cost of under $700. Vercel validated the exploit, paid Yibelo the top single payout of $50,000, and coordinated responsible disclosure with Linux kernel maintainers.

Linux networking primer: sk_buff and checksum offloading

CVE-2026-99999 only makes sense with some background on how the Linux kernel handles checksum offloading and the sk_buff (socket buffer) data structure.

Every packet sent over IPv4 or IPv6 needs a checksum to confirm data integrity in transit. Computing that checksum in software for every packet is CPU-intensive, especially in high-throughput cloud environments, so modern operating systems and network interface cards (NICs) offload it. With virtio-net (the standard paravirtualized network driver for KVM and Firecracker), the guest VM builds the packet payload but leaves the checksum incomplete.

The guest attaches metadata to the packet header before passing it to the host. In effect, it tells the host kernel: “I have built the packet, but you need to calculate the checksum and insert it at this specific offset before transmitting it.”

The kernel tracks this state in the sk_buff structure. When a packet needs deferred checksum calculation, the kernel marks the buffer with the CHECKSUM_PARTIAL flag. The guest fills in two fields of the virtio-net header, which the host kernel maps to the sk_buff:

1. csum_start: the byte offset from the beginning of the packet data where the checksum calculation should begin.
2. csum_offset: the byte offset from csum_start where the final 16-bit checksum result should be written.

Under normal operation this works. The host’s networking stack routes the sk_buff through the IPv4 or IPv6 layers, and just before handing the packet to the physical NIC driver (or fragmenting it), it calls the helper function skb_checksum_help(). That function reads csum_start and csum_offset, computes the checksum of the payload, and writes the 16-bit result directly into the packet buffer in memory.

PwnEscape lives in this mechanism. A deferred write whose location the guest controls.

The core vulnerability: trust inversion in skb_checksum_help()

The root cause of CVE-2026-99999 is a time-of-check to time-of-use (TOCTOU) state mutation, which shows up as a trust inversion in the kernel’s IPv4 stack.

When a packet from a guest VM reaches the host’s networking stack, the kernel runs a series of validation checks. It verifies the IPv4 header structure, confirms the version, validates the header length, and looks for malformed options. Once a packet passes these ingress or routing checks, the kernel treats the IPv4 header as trusted and moves on to the payload and routing logic.

The flaw is that the kernel lets less-trusted checksum metadata (csum_start and csum_offset) modify the packet buffer after the IPv4 header has been validated. Before the patch, skb_checksum_help() did not check whether the guest-supplied csum_start and csum_offset pointed to a location safely inside the payload or transport header (TCP or UDP).

An attacker inside the guest can craft a malformed packet whose checksum metadata tells the host to write the computed 16-bit checksum directly into the IPv4 header. The kernel has already validated that header and cached its assumptions about it, and it does not re-validate after the deferred write. The attacker can therefore change critical IPv4 header fields mid-flight and subvert the kernel’s internal state.

Exploitation mechanics: the IHL mutation and out-of-bounds read

Yibelo’s exploit chain turns a metadata overwrite into a reliable, repeatable host memory disclosure primitive. It unfolds in five steps.

rafting the malformed packet

The attacker builds a minimal IPv4 packet inside the guest VM. It is 28 bytes long: a standard 20-byte IPv4 header and 8 bytes of payload (such as a UDP header). The first byte of an IPv4 header holds two 4-bit fields, the Version (4 for IPv4) and the Internet Header Length (IHL), which gives the header length in 32-bit words. A 20-byte header has an IHL of 5, so the first byte is 0x45 (Version 4, IHL 5).

Initial kernel validation

The guest passes the packet to the host through the virtio-net interface with CHECKSUM_PARTIAL metadata. The host kernel runs the sk_buff through the IPv4 stack, reads 0x45, confirms the header is 20 bytes, and marks it structurally sound. Its internal pointers now assume the payload begins at byte 20.

The deferred checksum write

As the packet moves toward the egress or fragmentation path, the kernel calls skb_checksum_help() to fulfill the guest’s offload request. The attacker has set csum_start and csum_offset so that the 16-bit checksum write lands on the first byte of the IPv4 header. By choosing the 8 payload bytes carefully, the attacker makes the checksum come out as a value whose relevant byte is 0x4f. When skb_checksum_help() runs, it writes that value over the first byte of the IP header.

The IHL mutation

The write silently changes the first byte of the packet from 0x45 to 0x4f. The Version stays 4, but the IHL goes from 5 to 15. Under the IPv4 specification, an IHL of 15 means a 60-byte header (15 x 4 bytes). The header has changed after validation.

Triggering the out-of-bounds (OOB) read

The packet then reaches the kernel’s fragmentation routine (such as ip_do_fragment()). That code reads the IPv4 header to find where the header ends and the payload begins, so it can slice the packet into MTU-sized fragments. It reads the mutated IHL and concludes the header is 60 bytes long, but the sk_buff holds only 28 bytes of linear packet data. To fill the gap, the kernel reads the next 32 bytes of memory adjacent to the packet buffer in the kernel heap.

Those bytes belong to whatever data structures the slab allocator placed next to the sk_buff. The kernel packs them into the outgoing fragments and transmits them. The guest reassembles the fragments and extracts 32 bytes of host memory. Sending thousands of these 28-byte packets lets the attacker keep leaking the host’s kernel heap, which exposes memory layouts, cryptographic keys, pointers, and credentials.

Weaponizing the primitive: bypassing KASLR and reaching host root

In lab environments built to mirror Vercel’s production architecture, Yibelo chained the 32-byte leak into a full guest-to-host KVM escape with arbitrary code execution as root on the bare-metal host.

Modern Linux kernels use KASLR (Kernel Address Space Layout Randomization) to randomize the locations of kernel functions and data structures, which makes exploitation harder. The continuous 32-byte heap leak lets an attacker bypass it. Leaked heap data exposes known kernel pointers, the layout of the host’s slab allocators, and critical structures such as process credentials (cred structs) and function pointers like modprobe_path.

With the memory layout mapped, the attacker uses the same checksum offloading mechanism to build an arbitrary kernel write primitive. Through sk_buff lifecycle manipulation, heap grooming, and secondary networking bugs, the attacker can make the host kernel overwrite a chosen kernel pointer with an address the guest controls.

In the lab demonstration, the arbitrary write overwrote the modprobe_path variable or altered the cred structure of the Firecracker VMM process on the host. When the host next performed a privileged operation, it ran a payload the guest had injected, which gave the attacker a root shell on the bare-metal EC2 host.

The memory leak was confirmed against live production Vercel sandboxes, but the full host-root RCE chain was demonstrated only in controlled lab environments. Even so, a reliable, repeatable host-memory leak breaks the cloud environment’s security boundary and makes a full VM escape a matter of engineering effort. Yibelo also showed that two malformed packets reliably crash the host, taking down the bare-metal machine and every other tenant microVM on it.

Why this affects cloud providers beyond Vercel

Earlier VM escapes were tied to specific hypervisors or virtual device emulators. VENOM (CVE-2015-3456) exploited the virtual floppy drive controller in QEMU, and Cloudburst targeted the VMware virtual display driver. A provider that didn’t use that virtual hardware was immune.

PwnEscape does not depend on Firecracker, KVM, QEMU, or any other hypervisor-specific code. It sits in the mainline Linux kernel’s IPv4 networking stack.

Whenever a guest VM sends traffic to the outside world, or to other VMs on the same host overlay network, that traffic passes through the host’s Linux networking stack to be routed, NATted, or bridged to the physical NIC. Almost every major cloud provider, including AWS, Google Cloud, Microsoft Azure, Oracle Cloud, and independent OpenStack or Proxmox deployments, relies on the Linux kernel for this, which makes PwnEscape a shared-infrastructure vulnerability.

An environment is potentially vulnerable if it lets guest VMs send CHECKSUM_PARTIAL packets through virtio-net (or a similar paravirtualized interface) into the host’s IPv4 stack. Yibelo noted that the flaw leads to VM escapes across multiple hypervisors, because the host operating system itself is the trust boundary being violated. Vercel’s sandbox is where the bug was hunted. Any multi-tenant setup that exposes the host networking stack to guest traffic carries the same exposure.

Remediation, patching, and defense in depth

The disclosure prompted an immediate response from the Linux kernel networking maintainers. The upstream fix, written by Red Hat’s Michael S. Tsirkin, was merged into the mainline kernel as commit 6785011f8b16 (“ipv4: validate checksum_start before completing checksum”).

The patch adds a validation check to the networking stack. Before skb_checksum_help() or the fragmentation routines act on a packet, the kernel now verifies that the csum_start offset points outside the validated IPv4 header and into legitimate transport or payload data. If the metadata targets the IP header, the packet is dropped or the offload request is ignored, which closes the mutation vector. A follow-up series titled “more virtio-net csum hardening” adds ingress validation so that uncommon partial-checksum states are resolved before they reach deeper into the networking stack.

Patching directives for system administrators

Where you apply the patch matters. The vulnerability is in the host’s packet-processing path, so updating the guest VM’s kernel does nothing to mitigate it. The host kernel is what gets exploited.

Administrators of bare-metal hosts need to update to the patched stable branches and reboot to load the new kernel into memory. The maintainers backported the fix to all actively supported stable branches. The first fixed version in each branch:

Stable Branch	First Fixed Version
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
7.3 (Dev)	7.3-rc7

Enterprise Linux distributions (RHEL, Ubuntu, Debian, SUSE) often backport security patches into custom kernel builds without changing the upstream version number. Check your vendor’s security advisories (Red Hat Security Errata, Ubuntu Security Notices) to confirm that commit 6785011f8b16 or its equivalent is in your running kernel.

Defense in depth: the Firecracker Jailer and seccomp

The Vercel incident shows the value of defense-in-depth designs like the Firecracker Jailer. Firecracker’s security model assumes the virtualization barrier may eventually fail, so a companion process called the Jailer launches it. The Jailer sets up strict cgroups, namespaces, and chroot environments, drops all elevated privileges, and applies aggressive seccomp-bpf (Secure Computing Mode) filters before executing the Firecracker binary. Those filters restrict which system calls the VMM process may make.

If an attacker exploits a user-space bug in Firecracker to escape the guest, they land inside the Jailer’s seccomp sandbox and cannot interact with the wider host OS. PwnEscape sidesteps the user-space VMM by targeting the host kernel’s networking stack. The Jailer and seccomp limit the blast radius of many hypervisor vulnerabilities, but they cannot protect a host whose kernel is compromised through a networking-stack OOB read. In cloud security, the host OS networking stack is part of the isolation boundary and needs the same hardening and patching as everything else.

What AI-assisted discovery changes

PwnEscape also changes the economics and methods of security research. A state-machine-level kernel logic flaw was found in three days with under $700 of LLM API compute, which points to a new phase of AI-augmented zero-day discovery. The sub-$700 compute bill is the number that stands out.

Finding a flaw like this used to take a team of elite kernel researchers weeks or months of manual auditing of the sk_buff lifecycle, custom syzkaller fuzzers, and analysis of millions of kernel panic logs. Omega-Pwn shows that pairing human expertise with a reasoning model like GPT-5.6 Sol sharply lowers the barrier to finding critical infrastructure vulnerabilities.

The model could hold much of the Linux networking stack in its context window, trace data flows across kernel subsystems, and spot the gap between header validation and deferred checksum writes. The human researchers supplied the strategic direction, the intuition that the IHL field was exploitable, and the laboratory validation that proved the VM escape.

For defenders and bug bounty programs, this means the volume of sophisticated, logic-based vulnerability reports will grow sharply. The same tooling can help threat actors discover and weaponize zero-days in critical infrastructure before patches exist. The industry will need to build AI into defensive code-auditing pipelines so that kernel maintainers and enterprise security teams can catch trust inversions and state mutations at machine speed.

Conclusion

PwnEscape needed no hypervisor exploit and no Firecracker zero-day. It needed only that the Linux kernel trust its own earlier validation of a packet whose header could still be rewritten by attacker-controlled metadata. That trust was misplaced, and the flaw affects every major cloud provider that separates customer workloads using the Linux networking stack.

The fix is available, and maintainers backported Michael S. Tsirkin’s patch across all stable branches. The window between disclosure and widespread enterprise patching still carries elevated risk. Administrators should verify that their bare-metal host kernels include the fix, reboot them, and watch vendor advisories for the follow-up “virtio-net csum hardening” patches.

Disclosure timeline

• August 18, 2026: Vercel launches the $1 million Sandbox security challenge on HackerOne.
• August 21, 2026 (Day 3): Paulos Yibelo (pwn.ai) reports the kernel flaw via the Omega-Pwn harness.
• September 2026: Private patch discussions and validation take place on the netdev mailing list.
• October 8, 2026: Fix accepted into the netdev tree; commit 6785011f8b16 is authored by Michael S. Tsirkin.
• October 14, 2026: Fix merged into the mainline Linux kernel and backported to stable branches.
• October 15, 2026: Public disclosure, CVE-2026-99999 assignment, and NVD publication.
• October 16, 2026: Vercel publishes official findings of the $1M challenge; technical write-ups go live.