Vercel Paid $50,000 for a KVM Escape That Has No CVE and No Patch. Every VPS Host Is Waiting for the Write-Up.

On October 3 security researcher Paulos Yibelo posted five words that every operator of a Linux virtualisation fleet reads differently from everyone else: “Full VM escape zeroday (guest>host root in industry standard hypervisors)! More soon.” Ninety minutes later Vercel’s chief executive Guillermo Rauch quoted the post and confirmed it: “We’ve confirmed a KVM 0day through our Vercel Sandbox bounty program. Affecting the industry’s gold standard solution for Linux virtualization. 2026 is wild! Thankful to Paulos and other researchers helping us make the most secure sandbox for agents. Full writeup coming.” Yibelo’s bounty screenshot shows the programme’s maximum of $50,000, the figure Vercel reserves for a report that “lets a threat actor read or modify another Vercel tenant’s data.”

That is the whole public record. There is no CVE, no affected kernel range, no statement of which processors are needed, no patch and, as The Register noted on October 6 after checking the kernel lists, “that’s all the info that has made it into the public view at this time.” What makes the gap matter is the layer the flaw sits in. Vercel Sandbox runs on Firecracker microVMs, and Firecracker, in its own words, “uses the Linux Kernel-based Virtual Machine (KVM) to create microVMs.” A bug in KVM is a bug in the hypervisor under Proxmox, OpenStack, oVirt, most VPS fleets sold in this industry and the sandboxes that AWS Lambda, DigitalOcean’s Managed Agents and Vercel itself sell to AI agent developers. Until the write-up lands, a VPS provider knows that a guest-to-host path exists in the code it runs and nothing about where.

Key facts

• The claim: Paulos Yibelo, a security researcher whose profile lists pwn.ai, reported a guest-to-host-root escape through Vercel’s Sandbox bounty on October 3, 2026; Vercel’s CEO confirmed “a KVM 0day” the same day and promised a full write-up.
• The money: $50,000, the per-report maximum of a programme that offered up to $1 million in total for breaking the Sandbox isolation boundary.
• The target: Vercel Sandbox runs each customer in its own Firecracker microVM with a dedicated guest kernel on bare-metal EC2; Vercel says “the microVM, not the container, is the security boundary.” Firecracker is the AWS-built virtual machine monitor behind Lambda and relies on KVM for isolation.
• Not public: a CVE, the affected kernel versions, whether nested virtualisation or a particular CPU family is required, a patch, or any kernel mailing-list discussion as of October 7.
• The year so far: Januscape (CVE-2026-53359, July), its arm64 sibling ITScape, Zapscape (CVE-2026-64561, August) and a VMware ESX escape (CVE-2026-47876, July) all broke the guest-to-host boundary in 2026; this is the first with no public fix.

A Bounty Built to Find Exactly This

Vercel opened the programme on August 18 with a post by Andy Riancho that described the stack with unusual precision: “Vercel Sandbox runs on bare-metal EC2 hosts. Each sandbox gets its own Firecracker microVM with a dedicated guest kernel, and inside that microVM a Linux container runs the operator’s code.” The container was declared out of scope; the microVM was the prize. Researchers were asked to attempt “Escaping the Firecracker microVM to the EC2 host, or reaching another tenant’s sandbox through the compute layer,” or to defeat the host-side network firewall without crossing the microVM at all. The programme ran to September 1, with triage for a month after, and Riancho promised that “after the program closes, we will publish a follow-up writeup of the techniques and the fixes we shipped.”

The first round produced, by SecurityWeek’s account of Vercel’s results on September 15, 1,285 reports, of which one was rated critical, seven high, 15 medium and 49 low, for about $325,000 in committed payouts, and none reached another customer’s data. The notable finds were two independent defects in the Linux kernel’s networking stack, one leaking host kernel memory and one crashing the host, which Vercel said “have wide implications since many major cloud providers isolate customer workloads using the same layer of the Linux kernel.” Vercel learned of those two weeks before the kernel maintainers did; fixes went into private review with CVEs pending. Vercel’s September tally already listed one critical finding; whether Yibelo’s escape is that report or a second one, and when it was submitted, is not public. The award screenshot is dated October 3.

Yibelo’s account describes him as a security researcher working on “sandboxes, ai, web/offsec research” and lists pwn.ai, Octagon Networks’ autonomous penetration-testing product. None of that tells a hosting company whether the path he found needs a specific Intel or AMD generation, nested virtualisation, a particular device model, or a kernel feature that a conservative VPS host has turned off.

What Firecracker Trusts, and Why That Is Everyone’s Problem

Firecracker is a virtual machine monitor that Amazon built for Lambda and released as open source. Its own site puts the pitch in numbers: boot in under 125 milliseconds, up to 150 microVMs per second per host, under 5 MiB of overhead per VM, and it is “powering 15 trillion+ monthly Lambda function invocations.” Fly.io, Koyeb and Kata Containers are among the listed users; DigitalOcean’s Managed Agents, which we covered in September, runs on it too. Its design document is explicit about where the isolation comes from: “The first layer of isolation is provided by the Linux KVM and the Firecracker virtualization boundary,” with seccomp filters, cgroups, namespaces and a jailer process as defence in depth around the Firecracker process itself.

Those extra layers defend the host against a compromised Firecracker process. They do not defend it against a flaw in KVM, which lives in the host kernel and runs with the host kernel’s privileges. That is the distinction Rauch’s phrase “industry’s gold standard solution for Linux virtualization” is pointing at. KVM is the same code whether the guest was started by Firecracker, by QEMU under Proxmox or OpenStack, or by a hosting company’s own libvirt scripts. A guest-to-host-root path in KVM is therefore not a Vercel bug or a Firecracker bug. It is, until the write-up says otherwise, a bug in the hypervisor beneath nearly every VPS sold in this industry.

The Fifth Boundary Break of the Year

2026 has already taught hosting providers what a KVM escape costs to handle. Januscape, CVE-2026-53359, was a 16-year-old use-after-free in KVM’s shadow paging found by Hyunwoo Kim and disclosed on July 6; it needed nested virtualisation and let a guest root user run code as root on the host, on Intel and AMD alike. OVHcloud received the alert on July 7, built a patched kernel the same day and spent a week rolling it across about a million virtual machines on tens of thousands of hosts. Zapscape, CVE-2026-64561, followed on August 6 from the same researcher and the same code family, and our coverage then made the point that a server without a single VM is still in range wherever an ordinary user can reach /dev/kvm and start a throwaway guest. Four days after disclosure CloudLinux had a patched kernel for one line, two in beta and the rest in preparation. On the VMware side, CVE-2026-47876 in the VMXNET3 adapter, rated 9.3, may let a guest administrator run code on the ESX host, and the fix needs a host restart.

Every one of those arrived with a CVE, a fixed version list and, within days, vendor kernels. That is the difference this time. Vercel has the report, has presumably patched or mitigated its own fleet, and has said a write-up is coming. The Register says it has asked both Rauch and Yibelo for additional details. We found no post on oss-security, no linux-distros embargo notice that has surfaced, and no kernel commit identified as the fix as of October 7. The silence is consistent with coordinated disclosure in progress, which is the right outcome for everyone except the operator who has to decide today what to do.

What a VPS Host Can Do Before the Patch Exists

Not much that is specific, and the honest list is short. The levers that reduced exposure to Januscape and Zapscape are the ones available now: disable nested virtualisation on hosts that do not sell it, since both of this year’s published KVM escapes required it, although Vercel says Sandbox runs on bare-metal EC2 hosts, so there is no reason yet to assume this one does; keep host kernels on a line that receives KVM fixes within days of upstream, which for most providers means a vendor kernel with live patching rather than a hand-built one; restrict /dev/kvm on shared servers that are not virtualisation hosts; and have the July runbook ready, because when the fix lands it will again be a reboot or a live patch across the whole fleet. For a reseller running on someone else’s KVM, the question to ask the upstream provider is whether it has a process for a KVM fix that arrives with no notice, and how long the July one took.

The remaining uncertainty is the write-up itself. Vercel’s programme terms make a published account of “the techniques and the fixes we shipped” part of the deal, and Rauch has repeated the promise. When it appears it will say whether this escape is another branch of the shadow-MMU family that produced Januscape and Zapscape, which would narrow it to the same nested-virtualisation configurations, or something new in a device emulation path that Firecracker’s minimal model exposes. The first would be the fourth fix of the year to the same corner of KVM. The second would be the one hosting providers have not rehearsed.

This article is based on public posts by the researcher and Vercel’s chief executive, Vercel’s own programme documentation, Firecracker’s documentation and The Register’s report; neither Vercel nor the researcher had published technical details by October 7, 2026, and nothing here should be read as a description of the flaw itself.