What the challenge produced

Vercel opened its $1M hacker challenge for Vercel Sandbox in August, inviting security researchers to escape the sandbox, and ran a parallel source-code and architecture review with Trail of Bits. Over two weeks the program drew 1,285 reports and paid out $242,000 in bounties. Its most consequential result was an upstream Linux kernel zero day.

No report demonstrated access to customer data. The severity breakdown of validated reports was:

  • 1 Critical
  • 5 High
  • 9 Medium
  • 42 Low
  • 32 Informative

Triage of the 1,285 submissions resolved them into 877 duplicates, 319 not applicable, 57 valid and 32 informative. The Medium, Low and Informative findings were small policy-boundary gaps — a firewall rule behaving differently than documented, or a field that trusted the guest more than it should.

A kernel defect in the networking stack

On day three, Paulos Yibelo (pwn.ai), a HackerOne researcher working from a standard sandbox without special access, found a flaw in the Linux kernel's networking stack. Crafted packets sent from inside the microVM enabled three distinct attacks: leaking host memory over the network, crashing the host, and executing code on the host.

In the memory-leak case, host memory — the machine shared with other tenants — appears in packets the guest sends over the internet, and can continue for as long as the guest keeps sending. It was demonstrated against Vercel production sandboxes. The crash and code-execution variants were demonstrated on the researcher's own KVM and Firecracker machines configured to match Vercel Sandbox. Two packets were enough to crash a host machine, shutting down every sandbox on it; the same flaw allowed commands to run with full administrator privileges on the host, breaking the isolation boundary.

Because nearly every major cloud provider isolates workloads at this same kernel layer, the defect is a shared-infrastructure risk. Vercel worked with the researcher on mitigation, coordinated with AWS and other industry partners to prioritize a fix, and the researcher engaged kernel maintainers on candidate patches. Fixes remain under private review and CVEs are pending, so Vercel is withholding details until the patches are public; the existence of the vulnerability is being disclosed because it was separately disclosed in public.

Building the disclosure picture

The public bounty was one of three tracks. Before it launched, Vercel ran internal live security assessments with full source access and support from the engineers who maintain Sandbox. Two Trail of Bits engineers were engaged to evaluate the security architecture.

Internal work also produced findings: Marcos Hernanz, a Vercel intern, found a cross-tenant data leak in the Linux device-mapper storage layer that let any sandbox read recycled disk blocks from previously deleted sandboxes.

Trail of Bits spent four engineer-weeks inside the repositories, with access to two enterprise test teams, and delivered 20 findings, each tested, confirmed and referenced to the exact code. Their architectural review concluded the virtualization boundary is sound: each sandbox runs on its own Firecracker microVM with a dedicated guest kernel, and the device model is deliberately tiny. No guest shares a running kernel with the host or with another tenant.

Three structural recommendations

On top of that assessment came three recommendations, all implemented:

  • Eliminate all trust in the guest. The control plane had accepted values returned by software inside the microVM, and every such value is tenant input. Anything crossing the boundary should now be derived server-side or signed with a key the guest cannot reach.
  • One policy, one decider. Egress enforcement had been split across subsystems that each parsed the same network policy independently and did not always agree. The replacement uses one canonicalization routine per data type, one component per decision, and revalidates connections when policy changes.
  • Assume the next zero day. Protections around each sandbox were strengthened to limit damage from a virtualization-software exploit: host kernels are kept current, nested virtualization is disabled, and Firecracker's jailer runs each microVM process with restricted permissions isolated from the rest of the host.

Cross-tenant snapshot restore, and its limits

The report Vercel calls its favorite illustration of why public bounties still matter after internal and white-box work arrived on day one. Snapshotting a sandbox requires the control plane to record where snapshot data landed, as {storage_url, size, checksum}. That answer came from software running inside the guest, and host services trusted it — a trust-boundary violation, since the guest is where untrusted code runs, and the host cannot treat its word as authoritative.

The researcher combined a known, documented container-escape primitive with this flaw. They intercepted the snapshot response inside their own sandbox and rewrote it, swapping the storage objects of two snapshots belonging to two separate accounts they owned, so that restoring "your" snapshot materialized the other account's entire filesystem. Each account could read and modify the other's files, verified with hashes, and the test resources were preserved for independent reproduction.

The attack had real limits. Targeting a specific victim required knowing that victim's internal snapshot storage key, a random 96-bit identifier generated per snapshot and never exposed through the API — it appears only inside the victim's own sandbox. Because the researcher owned both accounts, no path was demonstrated for a stranger to target another tenant. It was still treated as a priority fix, since a boundary that depends on a secret staying secret is not a boundary. Trail of Bits independently flagged the same root cause, confirming the finding was real and discoverable from two different angles.

The fix shipped within a week. The control plane now binds every snapshot object to the project that created it and rejects anything else; snapshot creation moved out of the guest-reachable environment into a host-side service; and storage paths are project-scoped with strictly validated URLs.

Why heterogeneity carried the challenge

What stood out in the incoming reports was how differently researchers approached the target. Some clearly know Linux namespaces and steered their agents straight at the kernel boundary; others went after network policies; many probed areas Vercel had not thought to put on the menu. Researchers filed at a volume that Vercel attributes to AI-speed hunting — 1,285 reports in two weeks — and every technique surfaced by the challenge feeds back into how workloads on Vercel Sandbox are protected, whether the individual finding was a zero day or a duplicate.