Vercel says sandbox challenge uncovered a Linux kernel zero-day
Vercel reports that its sandbox escape challenge uncovered a Linux kernel zero-day. The program received 1,285 submissions and paid $242,000 in bounties, with no customer data compromise reported.

TL;DR
- Vercel’s $1M sandbox escape challenge received 1,285 reports and paid $242,000 in bounties, according to Vercel’s results announcement.
- An AI-assisted researcher crossed the virtualization boundary through a Linux kernel flaw, according to Vercel’s account of the discovery.
- No reports demonstrated customer data compromise, Vercel said, although its technical findings document host-memory leakage in production.
Two packets could crash a host in a matching KVM/Firecracker test setup. A snapshot bug let a researcher swap filesystems between two accounts they controlled by rewriting a guest-side response, a spectacular trust-boundary footgun.
Linux kernel escape
Paulos Yibelo (pwn.ai), a HackerOne researcher, submitted the key report on day three of the August challenge. He worked from a standard sandbox with no special access.
The defect was in the Linux kernel’s networking stack. Vercel’s technical account distinguishes three demonstrations using specially crafted packets sent from inside a microVM:
- Host-memory disclosure, Vercel production sandboxes: host memory appeared in packets the guest sent over the internet. Leakage could continue as long as the guest kept sending.
- Host crash, researcher-owned test systems: two packets crashed the host, shutting down every sandbox running on it.
- Host code execution, researcher-owned test systems: the same flaw allowed commands to run with full administrator privileges on the host.
The crash and code-execution demonstrations used the researcher’s KVM and Firecracker machines configured to match Vercel Sandbox.
Kernel patches and CVEs
Upstream fixes remained under private review and CVEs were pending when Vercel published its October 14 findings, according to its disclosure notes. Yibelo had contacted kernel maintainers and helped develop candidate patches.
Vercel said it worked with the researcher, AWS and other industry partners to mitigate the vulnerability. It disclosed the flaw’s existence following a separate public disclosure, while withholding further technical details until patches become public.
Vercel describes the affected kernel layer as one used by almost every major cloud provider to isolate customer workloads, giving the defect shared-infrastructure implications.
Firecracker hardening
Trail of Bits delivered 20 findings after four engineer-weeks of white-box work, according to Vercel’s assessment summary. The firm also reviewed the architecture and concluded that its virtualization boundary was sound.
Each sandbox runs in a separate Firecracker microVM with a dedicated guest kernel and a deliberately small device model. Guests share no running kernel with the host or other tenants.
Vercel says it implemented three structural recommendations:
- Remove trust in the guest: derive boundary-crossing values server-side or sign them with a key inaccessible to the guest. The control plane had accepted values returned by software inside the microVM.
- Unify network decisions: replace independent interpretations of the same egress policy with one canonicalization routine per data type and one component per decision. Connections are revalidated when policy changes. The sandbox firewall is the documented egress-control surface.
- Restrict the host-side blast radius: keep host kernels current, disable nested virtualization and use Firecracker’s jailer to restrict each microVM process’s permissions and isolate it from the rest of the host.
Snapshot ownership
A day-one report exposed a separate control-plane trust flaw. Vercel’s snapshot findings describe this sequence:
- Snapshot software inside the guest returned
{storage_url, size, checksum}, which host-side services trusted. - The researcher combined a documented container-escape primitive with interception of that response, swapping storage objects between snapshots belonging to two accounts they owned.
- Restoring a snapshot materialized the other account’s filesystem, allowing both accounts to read and modify each other’s files.
Targeting another tenant required its internal snapshot storage key, a random 96-bit identifier unavailable through the API. The key appeared only inside the victim’s sandbox; the researcher demonstrated the attack using two controlled accounts, with no demonstrated path for a stranger to target another tenant.
Trail of Bits independently identified the same root cause. Vercel shipped a fix within a week:
- Bind every snapshot object to its creating project and reject mismatches.
- Move snapshot creation into a host-side service outside the guest-reachable environment.
- Use project-scoped storage paths with strictly validated URLs.
Recycled disk blocks
Vercel intern Marcos Hernanz found another cross-tenant leak in the Linux device-mapper storage layer, according to the internal assessment findings. A sandbox could read recycled disk blocks left by previously deleted sandboxes.
Report triage
Vercel classified 57 of the 1,285 submissions as valid in its published breakdown:
| Disposition or severity | Reports |
| --- | ---: |
| Duplicate | 877 |
| Not applicable | 319 |
| Valid: Critical | 1 |
| Valid: High | 5 |
| Valid: Medium | 9 |
| Valid: Low | 42 |
| Informative | 32 |
Meta crawler spike
In a separate operational update, Vercel reported excessive, repetitive requests from Meta’s crawler at more than 15 times GoogleBot’s baseline volume. The company said its work with Meta had normalized crawling volume and the incident was resolved.