Why Xen's Architecture Beats KVM For Agent Isolation

If you run AI agents on shared infrastructure, your hypervisor is the only thing standing between some potentially insecure code an LLM wrote 5 seconds ago impacting every other tenant on that shared host.

Most teams appear to be reaching for KVM out of pure convenience. After all, KVM is already available in the Linux kernel, well documented and supported by almost every orchestration tool. That convenience is genuinely desirable to many developers who are still inexperienced in this area. But this summer's run of KVM guest-to-host escapes is a clear reminder that convenience and isolation are different design goals. Platform and security teams alike need to know where the hypervisor lives, and how this matters more than how many bugs it has.

The Summer of KVM Guest-to-Host Escapes

Between June and September 2026, researchers disclosed three separate guest-to-host escapes in KVM, plus memory-safety bugs reachable by any process that can open /dev/kvm. Researcher Hyunwoo Kim (@v4bel) published 3 of them as a set, named the KVM Escape Trilogy.

Click to view more CVE's, we discovered more than 600+ that affect the KVM hypervisor. Likewise, you can track the entire list of Xen vulnerabilities in the same time window (significantly less).

There are two clear details that stand out from the above table. Zapscape and Januscape are exploitable from inside the guest, with no help from QEMU. And on distributions such as RHEL, /dev/kvm is world-writable, so the same bugs can double as local privilege escalation for any unprivileged user.

The real problem with KVM as the host kernel

KVM is not a separate hypervisor. It is a module inside the host Linux kernel, so the hypervisor's trusted computing base is the entire kernel: its scheduler, memory manager, filesystems, network stack and drivers. That realistically has 2 consequences for agent sandboxing. 

1. First, a bug in KVM's MMU code is a bug in ring 0 (the protection ring) of the host, so an escape lands directly as host root. 
2. Second, the host kernel that enforces isolation is also a general-purpose OS exposed to the same workloads, so any Linux kernel CVE, not only a KVM one, is a potential path across the boundary.

The bugs above also cluster in the most complex code KVM has, such as shadow paging and nested virtualization. Those are exactly the features agent platforms enable when they run sandboxes inside cloud VMs.

How Xen’s Type-1 Architecture Shrinks the Blast Radius

Xen is a type-1 hypervisor that runs beneath every OS on the machine, including the privileged control domain (dom0). Its core is a small fraction of the size of the Linux kernel, and it does not contain filesystems, a network stack or most drivers. That separation is what matters for untrusted workloads:

The result is not that simply that there are 0 bugs in Xen, but rather that Xen is designed where the most likely bugs land somewhere less valuable than host ring 0.

Xen Has Advisories Too, and That Is the Point

A CVE count alone does not prove Xen is safer. In the same window, the Xen Project published more than a dozen advisories: XSA-499 through XSA-508 on July 28 and XSA-509 through XSA-513 on September 8, covering grant-table races, vRTC emulation and device-model issues. What differs is the impact profile. Several of those advisories are denial of service or bounded information leaks. 

XSA-503, as an example, is an out-of-bounds read limited to Xen's own data, not other guests. Others sit in components like oxenstored or Tapdisk that can be moved out of dom0 or replaced. The KVM bugs above, by contrast, are full host compromises from inside a guest. 

So the honest claim, from our informed perspective, is not to simply focus on Xen having fewer bugs, but rather it’s that Xen's architecture makes a given bug less likely to become a full-blown escape, and gives operators more ways to contain the ones that do.

October 5: Vercel Discloses a KVM Sandbox Zero-Day

If there were any doubts that this discussion was theoretical, Vercel's October 5 disclosure made the risk considerably harder to ignore.

Security researcher Paulos Yibelo, through Vercel's Sandbox bounty program, reported a critical VM-escape vulnerability capable of breaking out of a sandbox and reaching the host. The reported impact included cross-tenant read and modification as well as remote code execution. At the time of Vercel's October 14 findings report, the exact vulnerable component, affected versions, exploit details, and any confirmed exploitation had not been made public.

That distinction matters. Vercel Sandbox runs untrusted workloads inside Firecracker microVMs on bare-metal EC2 hosts, with KVM underneath. So it would be premature to attribute the vulnerability to KVM itself without the technical details. But the architectural lesson does not depend on that attribution.

Vercel's threat model assumes that code running inside a microVM has full guest-kernel access and will actively attempt to reach the host or another tenant. That is exactly the threat model an AI-agent platform should be designed for. Once arbitrary, potentially hostile code is inside the guest, the question is no longer whether the guest can be compromised. The question is what the attacker reaches next.

And that brings us to the next disclosure.

October 15: CVE-2026-99999 (PwnEscape) Explained

On the 15th of October, the vulnerability was tracked as CVE-2026-99999, or 

PwnEscape, and the technical picture became considerably more relevant to the KVM discussion.

The reported flaw sits in Linux kernel networking code rather than in Vercel's Sandbox config. The researcher demoed an escape from the VM to admin-level control of the host, while explicitly describing the result as a lab demonstration rather than a claim of root command execution against a vendor's production environment.

It’s important for us not to not turn a research demo into a claim that a particular cloud provider was compromised. But the security boundary being demonstrated is exactly the one that matters for shared infrastructure. Code running inside an isolated workload was able to cross into the privileged host layer.

Vercel's Sandbox was already designed around Firecracker microVMs, with each customer's code isolated in its own guest kernel on bare-metal hosts. There was no obvious app-level misconfiguration to blame. The problem was much deeper since the vulnerability within a privileged component of the underlying host was able to undermine the isolation that the sandbox was intended to provide.

This is the failure mode that is simply not acceptable for AI infrastructure. When the workload is untrusted, hardening the app, container, or guest is only part of the problem. The architecture of the layer underneath it determines how far a successful escape can travel.

What This Means for AI Agent Sandboxing

For AI-agent infrastructure, this is precisely the scenario we should be designing around. An AI agent is not simply another generic dumb application process. It can generate arbitrary code, install packages, invoke compilers, inspect its environment, and continuously probe the boundaries we give it. If that workload eventually finds a vulnerability in the isolation layer, we need the architecture underneath it to determine the blast radius.

That changes how we should evaluate hypervisors. We mentioned earlier in the blog post how we shouldn’t simply be asking how many CVEs does a specific hypervisor have? The answer is trivial and doesn’t address the real security concerns right now. Every serious hypervisor has vulnerabilities, and Xen is no exception to the rule. Instead, when the next vulnerability is found, we need to be asking ourselves where does that compromise land?

With KVM, the virtualisation layer is part of the host Linux kernel. A vulnerability in privileged KVM code therefore sits inside the same protection boundary as the kernel that owns the machine. And the attack surface does not stop at KVM itself since the host kernel also contains the scheduler, memory manager, networking stack, filesystems, and drivers.

Xen takes a different architectural approach. Its hypervisor sits beneath the operating systems, while device emulation and drivers can be separated into less-privileged domains. That does not make Xen bug-free. It means that there are more opportunities for a vulnerability to terminate somewhere other than host ring 0. That is the property we care the most about for agent isolation. Not a claim that Xen has zero bugs. Not a claim that KVM is inherently insecure. And not a simplistic comparison of CVE counts. The question is what happens when an attacker inevitably finds the next bug.

For infrastructure running untrusted AI agents, the safest architecture is the one that assumes the guest will eventually be compromised and makes that compromise as difficult as possible to turn into a host compromise. KVM earned its place by being ubiquitous, well supported, and easy to deploy. But when the workload itself is capable of actively attacking its environment, being everywhere is not the same thing as being the right wall.

FAQ

What is CVE-2026-99999, also called PwnEscape?

PwnEscape is a flaw in Linux kernel networking code, reported through Vercel’s Sandbox bounty program. In a lab demo it let code inside a Firecracker/KVM microVM cross into the privileged host layer: an escape from an isolated workload to admin-level host control, not a confirmed attack on any production environment.

Does CVE-2026-99999 mean KVM itself is insecure?

Not necessarily. The flaw lies in Linux kernel networking code, and full technical details were not public at disclosure, so attributing it to KVM itself would be premature. The architectural point stands regardless: when KVM is a module in the host kernel, a privileged-component bug can undermine the isolation a sandbox is meant to provide.

How is Xen’s isolation different from KVM’s for AI agents?

KVM runs as a module inside the host Linux kernel, so a bug in privileged KVM code lands as host root. Xen is a type-1 hypervisor beneath every OS, with a far smaller trusted computing base and device emulation and drivers pushed into de-privileged domains. A guest bug is more likely to terminate somewhere other than host ring 0.

Do CVE counts tell you which hypervisor is safer?

No. Every serious hypervisor, Xen included, has vulnerabilities; what matters is where a given bug lands. Many Xen advisories are denial of service or bounded information leaks, and some components can move out of dom0, while the KVM guest-to-host escapes are full host compromises. The better question is how far an inevitable compromise can travel.