Vercel Sandbox Survives Hacking Challenge: 1,285 Reports, $242,000 and a Linux Kernel Bug

Vercel has closed its hacking challenge for Vercel Sandbox, a cloud environment for running code in isolation. Over two weeks, researchers submitted 1285 reports, and Vercel paid out $242,000 in rewards. No report showed access to customer data. Still, the most serious finding turned out to be not in Vercel's code but in the foundation much of the cloud runs on: a zero-day in the Linux kernel's networking stack.

A zero-day on day three

The key report arrived on the third day of the program. Paulos Yibelo (pwn.ai), a HackerOne researcher, worked from an ordinary sandbox with no special privileges. He found a flaw in the Linux kernel's networking stack: specially crafted packets sent from inside a micro-VM allowed three different attacks.

• Host memory leak over the network. Memory from the machine that the sandbox shares with other tenants ended up in packets the guest sent out to the internet. The leak continued for as long as the guest kept sending traffic. The attack was demonstrated on live Vercel sandboxes.
• Host crash. Two packets were enough to bring the machine down, and every sandbox running on it went down too.
• Code execution on the host. The same flaw made it possible to run commands with full administrator privileges and break out of the isolation boundary.

The researcher reproduced the crash and the code execution on his own machines running KVM and Firecracker, configured to mirror Vercel Sandbox.

Almost all major cloud providers isolate customers at exactly this layer of the kernel, so the risk extends to shared infrastructure. Vercel says it worked with the researcher, as well as with AWS and other partners, to speed up a fix. In parallel, Yibelo contacted the kernel maintainers and prepared candidate patches with them. The patches are going through private review, no CVEs have been assigned yet, and details are not being disclosed. The company disclosed the vulnerability's existence because it had already begun to be discussed publicly.

An inside view: an intern and Trail of Bits

Besides the public bug bounty hunt, Vercel ran internal reviews with full access to the source code and brought in Trail of Bits. Not all findings came from outside. Vercel intern Marcos Hernanz found a cross-tenant leak in the Linux device-mapper storage layer: any sandbox could read reused disk blocks from previously deleted sandboxes.

Trail of Bits spent four engineer-weeks, assigning two specialists. They had full access to the repositories and two enterprise test environments. The result: 20 findings, each tested, confirmed and tied to a specific place in the code. The architecture review showed that the virtualization boundary is sound. Each sandbox runs in a separate Firecracker micro-VM with its own guest kernel, the device model is deliberately minimal, and no guest shares a running kernel with either the host or another tenant.

Three structural takeaways

The auditors made three recommendations, and Vercel says it has implemented all of them.

• Remove trust in the guest. The control plane accepted values returned by software inside the micro-VM, and any such value is effectively supplied by the tenant. Everything that crosses the boundary is now computed server-side or signed with a key the guest cannot access.
• One policy, one arbiter. Egress traffic control was spread across subsystems, each of which parsed the network policy on its own, and their decisions did not always match. Now there is a single canonicalization routine for each data type and a single component for each decision, and connections are rechecked when the policy changes.
• Assume the next zero-day will come. The defenses around each sandbox have been strengthened to limit the damage if the virtualization software is compromised. Host kernels are updated, nested virtualization is disabled, and Firecracker's jailer launches every micro-VM process with reduced privileges.

Practical takeaways for anyone running untrusted code

Sandboxes for AI agents and generated code are becoming a standard part of the stack, and this case shows where the risk actually lies. A micro-VM with a separate kernel did its job: even with a vulnerability in the host, no one reached customer data. But isolation does not remove the need to update host kernels or to distrust anything that comes back from the guest.

Teams that build their own sandboxes or choose a provider should check three things: whether the control plane accepts data from the guest without validation, whether network policy parsing is duplicated across components, and how quickly the provider rolls out kernel patches. Details on the CVEs will appear once the fixes are published, and teams will then need to check their own kernel versions and Firecracker configurations.