PwnEscape: Linux Kernel Flaw Breaks Agent Sandbox Isolation

Key Takeaways

PwnEscape (CVE-2026-99999) is a flaw in the host Linux kernel’s IPv4 networking code that lets a guest virtual machine send packets which leak host kernel memory, crash the host, and, in the researcher’s own lab, run code as root on the host [1][2][3]. The fault lies in the kernel that the hypervisor relies on, so the usual question of which hypervisor or microVM runtime is deployed does not settle whether a given environment is exposed. The code path has existed since Linux 2.6.27, released in 2008 [1][2].

The evidence for each impact differs, and defenders should keep the tiers separate. Host memory disclosure was confirmed against Vercel’s production sandboxes, whereas the host crash and root code execution were demonstrated only on the researcher’s own KVM and Firecracker systems configured to match Vercel’s [4]. Vercel reported that no submission in its program showed access to customer data [4]. No public exploit has been released, and no in-the-wild exploitation had been documented as of the sources reviewed [1][3][5].

The significance for AI safety teams is architectural. Many platforms that run agent-generated or agent-invoked code inside microVMs appear to treat the guest-to-host boundary as the final, strong layer of defense. PwnEscape shows that this layer inherits the vulnerabilities of the host kernel and that a vulnerability in a shared networking path can undercut it for every tenant on the machine. The only fix is to patch the host kernel and reboot, because no workaround has been published [1].

Background

Vercel opened a two-week bug bounty for its Sandbox product on August 18, 2026, with up to $1 million in rewards on offer [4][6]. Vercel Sandbox runs customer code in Firecracker microVMs, each with its own guest kernel, on bare-metal Amazon EC2 hosts [4][7]. Vercel’s final summary reports 1,285 submissions and $242,000 in bounties paid, with one Critical finding, which it identified as an upstream Linux kernel zero-day discovered by Paulos Yibelo of pwn.ai on the third day of the program [4]. Earlier interim figures differed: on September 15 an interim count of one Critical, seven High and roughly $325,000 in committed payouts was reported, whereas Vercel’s final summary lists five High and nine Medium findings, which is consistent with triage still being in progress at the time [4][6][8].

Public disclosure was staged. On October 3, Yibelo announced a full VM escape against KVM-based infrastructure and Vercel’s chief executive confirmed that a KVM zero-day had been validated through the program. At that point no CVE, affected version list, patch or write-up was available [8]. The kernel maintainers were notified on September 4, Red Hat’s Michael S. Tsirkin reproduced the issue on September 7, and the CVE and upstream fixes became public on October 14 and 15 [2][5]. AlmaLinux published patched kernels into its testing channel on October 16 [1]. Reporting also attributes the discovery to an AI-assisted research harness that the researcher estimated cost under $700 in API tokens [5]; we treat that cost figure as the researcher’s own estimate rather than independently verified.

A note on identifiers: the CVE number is unusual in appearance, and our direct search of NVD did not surface a record at the time of writing. The identifier is consistently used by the distribution, vendor and trade-press sources cited here, including AlmaLinux, which links it to the upstream commit and to Red Hat’s and the kernel CNA’s severity ratings [1][2][3][5]. The CVSS score and the Critical ratings attributed to Red Hat and the kernel CNA come from those secondary sources and were not checked against the underlying records. Readers should confirm the record in NVD, CVE.org or their distribution’s tracker before using the identifier in automated tooling.

The following table summarizes the key facts and where sources agree.

The commit identifier and stable version numbers in this table come from distribution and security-press sources rather than from the upstream kernel repository, so operators should confirm them against their vendor advisory or the upstream commit history before concluding that a host is patched.

Security Analysis

Mechanism

The guest controls checksum-offload metadata that accompanies packets it transmits. According to the analyses we reviewed, the host kernel first validates the IPv4 header, then later completes a deferred checksum by writing to a location derived from the guest-supplied csum_start value. Because that value was not constrained to lie outside the already-parsed header, the write can land on the header’s length field and change a 20-byte header into a 60-byte one after the kernel has made decisions based on the original [1][2][9]. When the fragmentation code later copies the header using the altered length, it reads past the real header and places roughly 32 bytes of adjacent host kernel memory into the options area of the outgoing packet [3][9].

Because the guest can repeat this for as long as it keeps sending, the disclosure is a repeatable stream rather than a single read [3][4].

Security engineers will recognize this as a time-of-check to time-of-use problem on packet metadata. One analysis generalizes the lesson as any deferred, attacker-influenced write into data that has already been validated, and recommends re-validating security-relevant fields after any step that can mutate them [9]. The upstream fix follows that logic by rejecting packets whose checksum start lies inside the IPv4 header, applied across five networking code paths; Tsirkin described it as a defense-in-depth measure [2][3][5].

What was demonstrated and what was not

The three outcomes carry different evidentiary weight. Memory disclosure was shown against production Vercel sandboxes, while host crash and root execution were shown on the researcher’s matching lab configuration [4]. The researcher withheld the allocator-sensitive portion of the chain that converts the leak into controlled writes, so the community cannot yet assess how readily the lab result generalizes to hosts with different kernel configurations, memory layouts or hardening [2]. We therefore regard root execution on arbitrary production hosts as plausible but unproven. Practical leak value also depends on what kernel structures happen to sit near the leaked bytes, and because leaked data appears in outgoing packets it may be observable to egress inspection where that is deployed [9]. These are analysts’ caveats rather than vendor guarantees and should not be read as mitigations.

Why agent sandboxes are a particular concern

Agent runtimes make this class of bug more consequential for three reasons, each of which is an inference from the public record rather than a reported fact. First, agent platforms deliberately run code that no human has reviewed, and prompt injection or a malicious tool can turn an otherwise benign agent into an attacker holding guest-level code execution; the prerequisite for PwnEscape is exactly that foothold [1]. Second, microVM platforms commonly colocate many tenants’ agents on the same physical host and share one host kernel, so a leak or crash affects neighbors, and the Vercel summary and trade reporting both note that the host crash would take down every VM on the machine [4][5]. Third, agent sandboxes typically have outbound network access, since agents call APIs and fetch packages, and this flaw is exploited through outbound packets. A deny-by-default network posture narrows what a guest can send but cannot remove the abnormal packet path itself, because the malformed packets are crafted at the virtual NIC level, so egress policy should be viewed as a detection and containment aid rather than a fix [9].

Other reporting indicates that the exposure is not limited to one hypervisor. The root cause sits in code reached from virtio-net and TAP or vhost paths in the host kernel, and the sources describe KVM with Firecracker as the demonstrated configuration [4][9]. We also consider it possible that container runtimes exposing the host network stack to untrusted workloads could be reachable, and that gVisor’s architecture may limit impact; these are our own inferences rather than claims from the cited analyses, and we have not verified them against a proof of concept. A vendor-authored analysis from Edera argues that Xen’s separation from the host operating system would have limited the blast radius of a flaw of this type. That position comes from a company selling isolation technology, and it should be weighed accordingly [7].

Place in the 2026 pattern of boundary failures

PwnEscape arrives after other guest-to-host and container escape disclosures this year, including the KVM shadow-MMU flaw known as Januscape and the futex flaw GhostLock, both of which CSA has analyzed [10][11]. Trade reporting counts it as at least the fifth guest-to-host breach of 2026 [8]. The recurring lesson across these cases is that shared kernels have repeatedly failed across trust boundaries, and that the quality of the surrounding architecture determines how much an attacker gains from each failure. Vercel’s own post-challenge summary reports that a white-box review by Trail of Bits led it to stop trusting guest-provided values in the control plane, centralize policy decisions, and assume future vulnerabilities when layering protections [4]. That framing is worth adopting for any operator of agent sandboxes, because it plans for the failure rather than the patch.

Recommendations

Immediate Actions

Operators of any infrastructure that runs untrusted or agent-generated code in KVM guests should identify host kernels first, since updating guest kernels does not mitigate the issue [3]. Apply vendor kernel updates that include commit 6785011f8b16 or the stable releases listed above, and reboot into the patched kernel, because a loaded but unrebooted fix does not protect the running host [2][3]. Distribution backports use their own version strings, so verify against the vendor advisory; AlmaLinux, for example, lists kernel-4.18.0-553.174.2.el8_10, kernel-5.14.0-687.57.2.el9_8 and kernel-6.12.0-211.66.2.el10_2 for versions 8, 9 and 10 [1]. Managed-platform customers should ask their provider in writing whether host kernels have been patched, since customers cannot patch the host themselves. Prioritize multi-tenant hosts and any host where one tenant’s guests share kernel state with another’s.

Short-Term Mitigations

Because no workaround exists, short-term effort should go toward reducing exposure and improving detection while patching proceeds [1]. Where feasible, avoid colocating higher-sensitivity agent workloads with untrusted code on the same host, and avoid keeping long-lived secrets in host-resident memory that a kernel leak could expose; tenant-held keys and short-lived per-task credentials reduce what a leak is worth [9]. Consider egress inspection that flags IPv4 packets from guests carrying unexpected options or headers longer than the guest’s normal traffic, noting that this is an untested heuristic derived from the published mechanism and not a vendor-validated detection, and that it could produce false positives or a false sense of security [9]. Review hardening that reduces the host kernel’s attack surface, such as the restricted Firecracker jailer configuration and disabled nested virtualization that Vercel describes in its own deployment [4]. These are general defense-in-depth steps; nested virtualization is not a dependency of this flaw, and none of these measures was shown to block it. Finally, track the pwn.ai and Vercel follow-up write-ups, which the researcher and Vercel have said will describe the techniques and fixes, and re-assess once the full chain is public [2][8].

Strategic Considerations

Treat the host kernel as part of the tenant boundary and include it in vulnerability service-level objectives for any platform running agent code. A response that does not depend on any single patch arriving on time is to design for the assumption that a guest will eventually escape its first boundary. That means keeping credentials, signing keys and cross-tenant data out of reach of the host kernel’s memory where possible, using per-task identity rather than ambient authority, and separating workloads by trust level across hosts and not only across guests. Teams selecting an isolation tier for agent runtimes should record the specific adversary assumptions behind that choice and the shared components the tier still depends on, since a microVM remains dependent on its host kernel and VMM. Procurement and due-diligence questions for sandbox providers should ask about host patch latency, kernel live-patching capability, tenant placement policy and bug bounty or external review practices, and should treat the provider’s responses as evidence to be revisited when disclosures like this one arrive. Finally, platform operators should expect more such disclosures: Vercel’s account describes AI-assisted researchers producing a large volume of reports in two weeks, which suggests that the cost of finding kernel flaws is falling for attackers and defenders alike, although submission counts are an imperfect proxy and the harness cost is self-reported [4][5][6].

CSA Resource Alignment

CSA’s Januscape research note on the KVM shadow-MMU escape is the closest prior work on the hypervisor side of this problem [10]. It addresses a root-privileged guest escaping to the host and gives guidance on nested virtualization exposure and on the need to apply coupled kernel commits. PwnEscape differs in mechanism and does not appear to depend on nested virtualization, but the operational lessons carry over: inventory the host kernels, confirm that all required fixes are present rather than assuming one commit is enough, and ask providers about their patch status.

CSA’s GhostLock note covers a long-lived Linux kernel flaw that crosses container boundaries and gives similar cause to treat the shared kernel as a trust boundary [11]. Read alongside PwnEscape, it supports the view that kernel patch cadence is a primary control for any environment where unreviewed code executes, whether that environment is a container or a microVM.

For agent-specific design guidance, CSA’s research note on sandboxing agentic AI recommends matching the isolation tier (process, container or microVM) to the adversary assumption and pairing it with deny-by-default egress, per-task credentials and tamper-resistant audit [12]. PwnEscape does not contradict the recommendation to use microVMs for untrusted agents, but it qualifies it: a microVM is stronger than a container against many threats yet still depends on host kernel hygiene, which makes the credential and audit controls in that guidance the layers that bound the damage when the isolation layer fails. The note’s incident corpus and reference architecture are therefore a useful baseline for the strategic recommendations above.

Where the findings touch control requirements, CSA’s AI Controls Matrix (AICM) v1.1 provides the control catalog for threat and vulnerability management and for infrastructure and virtualization security, and it is the appropriate place to anchor patch-latency and tenant-isolation requirements for AI workload platforms [13]. For threat-modeling agent runtimes that execute untrusted tool output, CSA’s MAESTRO framework offers a layered approach that places infrastructure-level compromise alongside agent-level risks [14].

References

[1] AlmaLinux OS Foundation. “PwnEscape (CVE-2026-99999): Patched kernels available in testing.” AlmaLinux Blog, October 16, 2026.

[2] SOC Prime. “CVE-2026-99999: Critical PwnEscape Linux Kernel Flaw Enables Guest-to-Host Escape.” SOC Prime Blog, October 2026.

[3] The Hacker News. “Critical PwnEscape Linux Kernel Vulnerability Lets Guest VMs Read Host Memory.” The Hacker News, October 15, 2026.

[4] Vercel. “Findings from the $1 Million Vercel Sandbox Challenge.” Vercel Blog, October 14, 2026.

[5] webhosting.today. “Linux kernel flaw PwnEscape lets a virtual machine read its host’s memory; upstream fixes are out.” webhosting.today, October 16, 2026.

[6] SecurityWeek. “$1 Million Sandbox Challenge Uncovers Linux Kernel Flaws.” SecurityWeek, September 2026.

[7] Edera. “Xen vs KVM Hypervisor Security After CVE-2026-99999.” Edera, October 2026.

[8] webhosting.today. “Vercel Paid $50,000 for a KVM Escape That Has No CVE and No Patch.” webhosting.today, October 8, 2026.

[9] PlayCISO. “PwnEscape: How Untrusted Checksum Metadata Rewrote a Validated Packet Header and Leaked Host Memory.” PlayCISO, October 2026.

[10] Cloud Security Alliance. “Januscape: 16-Year-Old KVM Flaw Enables VM Escape.” CSA AI Safety Initiative, July 2026.

[11] Cloud Security Alliance. “GhostLock: 15-Year-Old Linux Kernel Flaw Grants Root, Escapes Containers.” CSA AI Safety Initiative, July 2026.

[12] Cloud Security Alliance. “Sandboxing Agentic AI: Least-Privilege Patterns for MCP and Coding Agents.” CSA AI Safety Initiative, May 30, 2026.

[13] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, 2026.

[14] Cloud Security Alliance. “MAESTRO (Agentic AI Threat Modeling).” Cloud Security Alliance, 2026.