- Vercel's $1M Sandbox challenge drew 1,285 reports in two weeks, including a Linux kernel networking flaw. Vercel says no report showed anyone accessing customer data.
- A separate finding showed the host trusting snapshot details returned from inside the guest, a design error Vercel fixed within a week.
- Ask vendors what they accept from inside isolated environments and which single component makes each policy decision.
Some of the costliest boundary failures are not failures of the wall. They are failures of what the wall's keepers choose to believe. Vercel's report on its $1M Sandbox challenge contains both kinds. The quieter one is the one executives should study.
In August, Vercel invited security researchers to try to escape Vercel Sandbox. Each sandbox runs in its own Firecracker microVM, a small, lightweight virtual machine. Vercel also asked Trail of Bits to review its source code and security design.
On October 14, Vercel published the results. It received 1,285 reports in two weeks and paid $242,000 in bounties. Vercel says no report showed anyone accessing customer data.
The kernel flaw: shared ground gives way
Three days in, Paulos Yibelo of pwn.ai reported a bug through HackerOne. It sits in the part of the Linux kernel that handles network traffic. Vercel calls it the most important report of the program.
The researcher sent specially crafted packets from inside a microVM. That triggered three different attacks.
The first leaks memory from the host into packets the guest sends out. The host is the machine a sandbox shares with other customers. Vercel says this worked against its production sandboxes.
The second attack crashed the host with two packets. That shuts down every sandbox running on it. The third gave the researcher administrator-level control of the host, and a way out of the sandbox.
The crash and takeover were shown on the researcher's own machines, built to match Vercel's setup. Vercel says almost every major cloud provider isolates workloads on this same kernel layer. So a defect there is a shared risk.
Details are limited. Fixes are under private review and the CVE identifiers are still pending. Vercel is disclosing that the flaw exists only because it was separately disclosed in public. It is withholding further details until the patches are public.
The flaw that taught more: a host that believed its guest
A smaller finding shows a habit many platforms share. A snapshot saves a copy of a sandbox. Afterward, the platform must record where that copy went, how large it is, and its checksum.
Vercel's control plane took those details from code running inside the guest. Services on the host believed them. The guest is where customers run untrusted code, so that was a mistake.
Think of a bank teller who lets a customer fill in the bank's own ledger. The researcher paired a known container-escape technique with this misplaced trust.
The researcher caught the reply inside their own sandbox and edited it. Two snapshots, owned by two accounts the researcher controlled, were pointed at each other's storage. Restoring one account's snapshot then produced the other account's whole filesystem. Each account could read and change the other's files.
The limits matter. To aim the swap at a stranger, an attacker would need that person's storage key. It is a random 96-bit identifier that the API never exposes. Vercel says there was no demonstrated path to attack another customer.
Vercel fixed it as a priority anyway. Its reasoning: if safety rests on one hidden value staying hidden, the design has no real barrier at all.
The fix shipped within a week. Snapshot creation moved to a service on the host side. Each snapshot is now tied to the project that created it.
What the outside review said
Trail of Bits spent four engineer-weeks in the source code. It delivered 20 findings. It also judged the core design sound: the host and each customer's sandbox never run on the same live kernel.
It also made three structural recommendations, which Vercel says it has put in place.
First, remove all trust in values the guest returns. Second, let one component make each policy decision. Network rules had been read by several subsystems, and they did not always agree. Third, plan for the next zero-day. That means current host kernels, nested virtualization switched off, and Firecracker's jailer limiting what each microVM process can do.
The lesson: isolation is what you refuse to believe
This shows that strong isolation is not something you buy once. It is a discipline of refusing to accept input from the side you do not control. The kernel bug was a hole in shared ground. The snapshot bug was a hole in a decision.
Vercel points to the snapshot report, filed on day one, as proof that a public bounty pays off. It came even after internal tests and a review with full source access. Trail of Bits flagged the same root cause on its own. Two different approaches reached the same flaw.
Vercel also ties the flood of reports to researchers working at "AI speed". It says some aimed their agents straight at the kernel boundary.
For buyers, the point is practical. Outside researchers can now test at that pace. Vercel's own account shows internal review had not found everything.
Questions to put to your team
Ask every vendor that runs your code, or your customers' code, on shared infrastructure what it accepts from inside the isolated environment. Ask whether those values are recalculated or signed on the host side.
Ask who makes each policy decision, and whether more than one component reads the same rule. Ask how fast host kernels are patched. Ask how the vendor will tell you when a shared-layer flaw like this one comes to light.
Finally, ask whether outside researchers have tested the vendor, not only its own staff. A wall that holds is good news. A host that never takes the guest's word is better.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Vercel.
