Vercel Confirmed a KVM Zero-Day in the Sandbox That Runs Untrusted Code

Vercel has confirmed a KVM zero-day inside the sandbox that runs untrusted code. The escape means the boundary the company sells as isolation is the same boundary an attacker just crossed. For anyone running AI agents that execute untrusted code, that is the whole product promise on the line.

The boundary is the hypervisor, not the container

Vercel Sandbox does not lean on a container to hold tenants apart. Each sandbox runs inside its own Firecracker microVM on a bare-metal Amazon EC2 host. Vercel names the microVM, not the Linux container inside it, as the main security boundary. That matters for agent platforms. When an agent runs generated code, the container is the convenient part and the microVM does the protecting. A guest-to-host escape crosses the line that was meant to hold. Firecracker exists to make that line thin and fast, and it runs on KVM underneath.

Confirmed is a flaw. Claimed is root on the host

Vercel’s chief executive, Guillermo Rauch, said the company confirmed a KVM zero-day through its sandbox bounty program. The researcher, Paulos Yibelo, described the finding on October 3 as a full virtual machine escape, guest to host root. What an operator needs is still missing. There is no CVE, no affected kernel version, no processor requirement, no patch and no word on whether guest administrator access is required. Vercel paid its maximum single-report bounty of $50,000, the tier it reserves for cross-tenant access and microVM escapes to the host, as first reported.

What to do before the writeup lands

Do not read this as a container bug. Hardening the container changes nothing here. Watch Vercel and your Linux vendor for the promised writeup and any affected versions. If you run your own sandboxing on KVM or Firecracker, treat one escape as a fleet problem and keep host credentials off the sandbox network. The pattern repeats. Cloudflare’s sandbox flaw in September let one tenant read the last tenant’s disk, and a container escape shipped in Ubuntu without a fix. The isolation boundary is the thing to audit, not the code running inside it.

Three questions to ask this week. Which layer isolates your tenants, the container or the machine underneath it? If a guest reaches the host, what else can it reach from there? And what is your patch path for a hypervisor flaw with no CVE yet?