On 3 October 2026, two posts landed about ninety minutes apart. Paulos Yibelo, a security researcher, said he had a full virtual-machine escape zero-day (a brand-new hole, not yet patched, that lets a program step out of the pretend computer it was given). His words: guest to host root, in the hypervisors the industry treats as standard. Guillermo Rauch, Vercel’s CEO, answered that Vercel had confirmed a KVM zero-day through the Vercel Sandbox bounty, that it affects what he called the gold-standard way to virtualize Linux, and that a full write-up is coming.
New words in this piece are defined in parentheses the first time they show up. Read the sentence before the word. That sentence is the thing the word is naming.
If you only have two minutes
You run an agent (a program that writes and executes other programs, often code nobody reviewed). To keep that code off your real servers, you rent a sandbox (a fenced place where untrusted code is supposed to run without touching anything else). Vercel’s fence was not a container. It was a tiny virtual computer, and under that computer sits KVM, a piece of the Linux kernel. Vercel just paid the maximum bounty, $50,000, for a report whose award text puts the cause in the critical class: breaking out of that tiny computer onto the host, the class reserved for reading or changing another customer’s data. The exact trick is still blacked out. No public version list. No CVE number published as of 4 October. Do not “fix” it by moving the agent onto a shared-kernel container. That is a weaker fence, and Vercel already assumed an attacker owned everything inside the tiny computer.
The arrow that broke is the one from the guest kernel into KVM. Everything above that arrow was already treated as hostile.
What the two posts actually say
Keep the speakers separate. Yibelo wrote “full VM escape zeroday” and “guest to host root in industry standard hypervisors,” and attached the bounty screenshot. Rauch wrote that Vercel confirmed a KVM zero-day through the Sandbox bounty, thanked Yibelo, and said the full write-up is coming. Rauch did not repeat the words “host root.” The screenshot is Vercel’s own award text, so that part is Vercel speaking too. This piece does not fill in the black bar.
A computer, before any of those words
A program cannot touch the disk, the network, or the memory of another program by wishing. The chip runs instructions. A special piece of software is allowed to drive the devices. Everything else has to ask. That special piece is the kernel (the core of an operating system, the only code that is supposed to talk to the hardware directly). A running program outside the kernel is a process (one program, with its own memory, that has to ask the kernel whenever it wants the disk, the network, or more memory). The ask is a system call (a controlled doorway from a process into the kernel). If you remember only this, remember the doorway. Every later wall is a decision about who shares a kernel, and who gets a doorway into whose kernel.
A container is rules, not a second computer
People say a container (a box around a process) “isolates” code. What it actually is: a set of rules inside one kernel. Namespaces (filters on what a process is allowed to see: which files, which network, which other processes) hide the rest of the machine. Cgroups (counters and caps on CPU, memory, and disk) stop one box from eating the whole machine. Seccomp (a filter on which doorways the process may use) throws away system calls the box should not need. None of that creates a second kernel. The host kernel still performs every system call. A bug in that kernel is a bug in the floor under every container on the machine.
That picture is why a container escape (a bug that gets a process out of those filters and into the host kernel’s full power) is a known, ordinary kind of bad day. It is also why Vercel said, in the bounty rules, that a container escape which only reaches the guest operating system is out of scope. They do not pay for it. They already assume the attacker is root inside the container, and even that the attacker has the whole guest kernel. The rules call namespaces a developer convenience, not the security boundary.
A virtual machine is a second computer, with a catch
A virtual machine (a pretend computer, with its own kernel, running on a real one) looks like the fix. The code inside gets a guest (the pretend computer, and the operating system installed on it). The real machine is the host (the physical computer, and the operating system that actually owns the hardware). For the guest to run, something on the host has to pretend to be a CPU, a disk, and a network card. That something is a hypervisor (the program that runs guests and is supposed to stop a guest from becoming the host).
Old hypervisors did the pretending entirely in software. That is slow, and the pretending program is a huge doorway. Modern chips grew an extra mode so the pretending can be done mostly by the processor. Intel’s version is VT-x, AMD’s is AMD-V (hardware virtualization: extra modes in the CPU that run a second operating system behind a hardware wall, instead of a program faking every instruction). Linux’s way of using that extra mode has a name.
KVM is the Linux kernel agreeing to be the hardware
KVM, short for Kernel-based Virtual Machine, is a module (a piece of kernel code you can load) that turns the Linux kernel into a hypervisor. It has been in the mainline kernel since Linux 2.6.20, released 5 February 2007. It does not work on a chip without VT-x or AMD-V. The guest does not sit “under” Linux, and Linux does not sit “under” a separate hypervisor product. KVM lives inside the host kernel. A normal program, often QEMU or Firecracker, asks KVM to create virtual CPUs. Those virtual CPUs run the guest. When the guest needs a disk or a network card, it drops into KVM code, which is host-kernel code.
This is the sentence the news depends on. A bug in KVM is not a bug in the guest’s Linux, and it is not a bug in the agent’s Python. It is a bug in host-kernel code that the guest is allowed to poke, on purpose, every time the pretend computer needs the real one. “Guest to host root” means: code that was supposed to stay in the pretend computer got the powers of the administrator of the real one. Root (the all-powerful account on a Unix machine) on the host can see the other guests that share that machine.
A cartoon you will see this week splits hypervisors into “type 1, on the metal” and “type 2, on top of a host operating system,” and then files KVM under type 2 because “there is a Linux.” That cartoon hides the bug. KVM is not an app sitting on Linux. It is Linux, in kernel mode, using the chip’s virtualization mode. The diagram above is the one to keep.
Firecracker is a small program that asks KVM for a tiny computer
A microVM (a virtual machine with almost no fake devices, built to boot fast and to give each tenant their own kernel) is the product shape AWS open-sourced as Firecracker. Firecracker’s own readme says the main piece is a virtual machine monitor (the program that creates and watches one virtual machine; people abbreviate it VMM) and that this monitor uses KVM to create and run microVMs. Inside one Firecracker process there is an API thread, a VMM thread, and one thread per virtual CPU. The design doc says those virtual-CPU threads are created through KVM and run the KVM_RUN loop. That loop is the guest actually executing.
Firecracker tries to be small on purpose. It does not emulate a full PC. Fewer fake devices means a smaller doorway. It also tries not to run as root. A helper called the jailer (a starter process that sets up the tight box, then gives up power) creates the cgroups and the chroot, drops privileges, and only then starts Firecracker. After that, Firecracker is an unprivileged process. People hear “unprivileged” and relax. Don’t. The guest’s path into the host still enters KVM, and KVM runs in the host kernel, which is much more privileged than the Firecracker process. A jail around the VMM does not jail the kernel module the VMM has to use.
The guest is assumed evil. The host is the prize.
Firecracker’s threat model says it out loud. Once a virtual CPU starts, treat it as malicious code. Containment is nested zones, from least trusted (the guest’s virtual CPUs) to most trusted (the host). Firecracker also says it does not filter network traffic. Everything leaving the guest is untrusted and should be filtered on the host. Two different walls: one is “can the guest become the host?”, the other is “can the guest talk to places it should not?”
How Vercel stacked the walls
Vercel Sandbox, the product the bounty was about, runs on bare-metal EC2 hosts. Bare metal (a physical machine you rent with no other company’s hypervisor underneath, so your software is the first software on that machine) matters here. There is no extra hypervisor below KVM to catch a KVM bug. Vercel’s challenge post says each sandbox gets its own Firecracker microVM with its own guest kernel, and inside that microVM a Linux container runs the customer’s code. Their sentence: the microVM, not the container, is the security boundary, so the customer’s code sits two layers away from the host. They assume that code is fully hostile: root in the container, full kernel access inside the microVM, and motivated to reach the host or another tenant.
The network half of the boundary is enforced on the host, outside the microVM, where code inside the sandbox cannot switch it off. The firewall checks outbound connections. Credentials can be injected at that boundary so the secret never has to live inside the guest. That design is still the right design. This bounty is not a story about the firewall. It is a story about the other wall, the one Vercel told researchers was the real prize.
Their concepts page, as of 4 October 2026, still says the microVM boundary “prevents escapes,” and that each sandbox boots an Ubuntu 26.04 image by default, or a custom image, or a snapshot. Hold both facts at once. The docs describe the intended model. The 3 October posts describe a break in that model. Ubuntu 26.04 being new does not save you. The guest operating system is above the bug Vercel named. Patching packages inside the sandbox does not patch KVM on the host.
Read the $50,000 sentence slowly
The program was a public HackerOne challenge, open from 18 August to 1 September 2026, with triage running through 1 October, a pool up to $1,000,000, and a cap of $50,000 per report. The cap is reserved for a bug that lets an attacker read or change another Vercel tenant’s data. Critical, on the public table, is $25,000 to $50,000, described as a microVM-to-EC2-host escape, or a cross-tenant read, modify, or remote code execution. Container escapes that only reach the guest are not in that table.
The screenshot in the 3 October post says Vercel awarded $50,000, repeats the “another tenant” rule, says the critical rows cover microVM-to-EC2-host escape and cross-tenant read, modify, or RCE, and then says this report’s root cause delivers exactly that class. The words “guest-controlled” are visible. The rest of the cause is a black bar. Paying the maximum and calling it that class is strong. It is not a published proof, a CVE, or a list of kernel versions. Headlines that say “every customer was read” are ahead of the text. Headlines that say “just a crash bug” are behind it. The text says: top of the critical band, cause still hidden, class is host escape and the cross-tenant damage that band exists for.
| What | Status on 4 October 2026 |
|---|---|
| KVM zero-day, confirmed by Vercel’s CEO | Said, in public, on 3 October |
| Guest to host root, researcher’s wording | Said by Yibelo. Not repeated verbatim by Rauch |
| $50,000, the per-report maximum | In the award screenshot he posted |
| Critical class: host escape and cross-tenant read, modify, or RCE | Award text says this root cause delivers that class |
| The actual bug, versions, patch | Black bar. Write-up “coming.” No CVE published yet |
| In-the-wild attacks against customers | Not claimed by Vercel or the researcher |
Who else stands on this floor
Firecracker is not a Vercel invention. AWS open-sourced it, and on 22 June 2026 AWS wrote that the new Lambda MicroVMs are powered by Firecracker, the same technology behind Lambda, which AWS said had powered more than 15 trillion monthly function invocations. Firecracker’s readme says it uses KVM. So the floor under a lot of “run this untrusted code safely” products is the same sentence: KVM held.
Vercel’s comparison page also says E2B runs each sandbox in a Firecracker microVM, and that Modal uses gVisor by default. gVisor (a second, smaller kernel that runs as an ordinary program and catches system calls, instead of using the chip’s virtualization mode) is a different wall, with its own bugs. It is not a free upgrade, and this piece is not telling you to migrate to it because of a redacted KVM bug. Know which wall you bought. A product name on a pricing page is not a kernel.
Do not file a Lambda incident off this tweet. Affected versions are not public. “KVM zero-day” means the bug is in that layer, not that every machine running any KVM from any year is sitting open. It does mean: if your agent box is Firecracker on Linux, the write-up is on-call reading, and until versions are named you cannot honestly tell a customer “we checked, we are fine” or “we were breached.”
The move that makes you less safe
The bad week looks like this. Someone reads “virtual machine escape,” panics, and moves the agent from a microVM onto a normal container on the host, because containers feel familiar and the ticket says “get off Vercel Sandbox.” You just deleted the second kernel. The agent now shares the host kernel, which is the floor Vercel refused to treat as the boundary. Their researchers were told a container escape was not even in scope, because the attacker is assumed to have it already.
The other bad move is inventing a patch. Randomly upgrading the host kernel, declaring the CVE you could not find, or telling customers the data was taken, are all ways to sound decisive with no evidence. The award is real. The mechanism is not public. Treat those as different facts.
What to do before the write-up
You can do this on Monday without the blacked-out primitive.
- Name the box. Where does untrusted agent code actually run: Vercel Sandbox, Lambda MicroVMs, E2B, your own Firecracker, a shared-kernel container, or a laptop?
- Count kernels. Does that code get its own kernel, or does it share the host kernel? If you cannot answer, you do not know whether this bug is about you.
- If there is a second kernel, name what sits under it. KVM, a cloud hypervisor you do not control, or something else. “We use isolation” is not an answer.
- List secrets that live inside the guest. API keys written into the sandbox filesystem, cloud tokens in environment variables inside the microVM, customer data copied in so the agent can “see” it. Those are on the wrong side of a wall that just failed a paid test.
- Prefer the pattern Vercel already described for the network wall: inject credentials at the host boundary so they never enter the guest. A broken compute wall hurts less when the guest never held the key.
- If two tenants must not be able to read each other, and they currently share a physical KVM host, split them onto different machines until the advisory names versions. A host-kernel bug is shared by every microVM on that machine. This is expensive. It is also the only containment you control while the patch list is secret.
- Do not replace the microVM with a shared-kernel container and call it remediation.
- Subscribe to the write-up, the Linux kernel advisory, and Firecracker’s changelog. Patch the version they name, not a version you hoped was close enough.
If your earlier threat model was “the network fence is enough,” read it again beside this. A network fence stops the guest calling home. It does not stop the guest becoming the host and reading the neighbor’s disk. TechWave already walked a network-fence miss in OpenAI’s DNS sandbox escape — HTTPS blocked, DNS trick scored as a miss. That was the other wall. This bounty is the compute wall. You want both, and you want secrets outside the guest either way.
What this piece is not claiming
Scope, not a scare headline. No public exploit write-up yet. No CVE number, CVSS score, or affected-version list was published as of 4 October 2026. This piece does not claim Vercel customers were robbed, and it does not claim your Lambda function is open. It does claim the isolation story most agent sandboxes tell — “it is a microVM, so a bug inside cannot become the host” — took a confirmed hit in KVM, the layer that story stands on, and the people who confirmed it paid the maximum amount their own rules reserve for cross-tenant damage.
When the write-up lands, the only question that matters is narrow. Which KVM code, which kernel versions, which Firecracker versions, and did the fix land on the host before you put the next secret in the guest. Everything else in this piece is the map you needed so that question is readable.
