Vercel's $1M sandbox challenge uncovers Linux kernel zero-day, pays $242,000 in bounties

Vercel has published the outcome of its $1M Sandbox challenge, a two-week public bounty that invited security researchers to break out of Vercel Sandbox. According to the Vercel blog, the exercise produced 1,285 reports, $242,000 in paid bounties and one zero-day vulnerability in the Linux kernel — the most severe finding of the program. The company states that no report demonstrated access to customer files, secrets or application data.

A kernel zero-day with industry-wide reach

The decisive report arrived three days in. Paulos Yibelo of pwn.ai, working through HackerOne from a standard sandbox with no special access, identified a defect in the Linux kernel's networking stack. Vercel says specially crafted packets sent from inside a microVM enabled three separate attacks: leaking host memory across the network, crashing the host machine, and executing code on the host.

The memory disclosure was demonstrated against Vercel's production sandboxes and could continue for as long as the guest kept sending. The crash and code-execution attacks were demonstrated on the researcher's own KVM and Firecracker machines matching Vercel Sandbox's configuration; two packets were enough to take down the host and, with it, every sandbox running on that machine.

Vercel treats this as a shared-infrastructure risk because nearly every major cloud provider isolates customer workloads on the same kernel layer. The company says it coordinated with the researcher, AWS and other industry partners on mitigation, while the researcher worked with kernel maintainers on candidate patches. Fixes are under private review and CVEs are pending, so Vercel is withholding technical details; it confirmed the vulnerability exists only because the flaw had already been disclosed publicly elsewhere.

Internal findings and the Trail of Bits review

Before opening the public bounty, Vercel ran live internal assessments and engaged Trail of Bits for a white-box review. Two Trail of Bits engineers spent four engineer-weeks with full repository access and delivered 20 findings, each tested and tied to exact code. Their architectural review concluded that the virtualization boundary is sound: every sandbox runs in its own Firecracker microVM with a dedicated guest kernel, no guest shares a running kernel with the host or another tenant, and the device model is deliberately minimal.

Trail of Bits also issued three structural recommendations, which Vercel has implemented. First, remove all trust in the guest: the control plane had accepted values reported by software inside the microVM — all tenant-controlled input — and anything crossing the boundary is now derived server-side or signed with a key the guest cannot reach. Second, consolidate egress enforcement: network policy had been parsed independently by multiple subsystems that did not always agree, and each decision now goes through a single canonical component, with connections revalidated when policy changes. Third, assume the next zero-day: host kernels are kept current, nested virtualization is disabled, and Firecracker's jailer runs each microVM process with restricted permissions.

Not every finding came from outside. Vercel intern Marcos Hernanez found a cross-tenant leak in the Linux device-mapper storage layer that let a sandbox read recycled disk blocks from previously deleted sandboxes.

1,285 reports, mostly noise

The report mix broke down as 877 duplicates, 319 not applicable, 57 valid and 32 informative. Vercel validated one critical, five high, nine medium and 42 low findings, plus 32 informative ones. The medium and low findings were largely small policy-boundary gaps, such as a firewall rule that behaved differently than documented. Vercel attributes the sheer volume to researchers now working at AI-assisted speed, and highlighted the diversity of approaches: some targeted the kernel boundary, others attacked network policies, and many probed areas Vercel had not thought to list.

The snapshot swap

One day-one report illustrates why Vercel runs a public bounty even after internal and white-box reviews. When a sandbox is snapshotted, the control plane recorded where the data landed — storage URL, size and checksum — based on an answer supplied by software inside the guest, which host services then trusted. The researcher combined that trust flaw with a documented container-escape primitive, intercepting and rewriting the snapshot response to swap the storage objects of two snapshots belonging to separate accounts. Restoring one snapshot materialised the other account's entire filesystem, and each account could read and modify the other's files, verified with hashes.

The limits matter. Targeting a specific victim would require knowing that victim's internal snapshot storage key — a random 96-bit identifier generated per snapshot, never exposed through the API and visible only inside the victim's own sandbox. The researcher owned both accounts, and no path was demonstrated for a stranger to target another tenant. Vercel still prioritised the fix, arguing that an isolation boundary which depends on a secret staying secret is not a sound boundary.

Why it matters

The headline finding is not a Vercel problem alone: a zero-day in a kernel networking layer used for workload isolation across the cloud industry has far broader reach, and practitioners should watch for the pending CVEs. The exercise also confirms a transferable design lesson for anyone building multi-tenant compute: values crossing a trust boundary must be derived or verified server-side, never accepted from inside a tenant's VM — a mistake Vercel made twice, in the snapshot flow and the control plane. Finally, the results show how public bounties, internal reviews and independent audits each catch different classes of bugs, and they preview the triage burden of AI-accelerated security research: of 1,285 reports, fewer than five percent were valid.