Vercel Sandbox Vulnerability Challenge: A Million-Dollar Bounty Uncovers a Linux Kernel Zero-Day

Vercel launched a million-dollar sandbox escape challenge, inviting security researchers worldwide to try to break through the isolation boundary of Vercel Sandbox. Within two weeks, it received 1,285 reports, paid out $242,000 in bounties, and discovered a Linux kernel zero-day affecting nearly every major cloud provider. The challenge not only exposed systemic risks in shared infrastructure but also provided the cloud security industry with a rare template for security stress testing.

Linux Kernel Zero-Day: Systemic Risk in Shared Infrastructure

What You Can Do by Sending Malicious Packets from Inside a microVM

On the third day of the challenge, HackerOne researcher Paulos Yibelo (pwn.ai) submitted the single most important report of the entire program. Working in a standard sandbox environment with no special privileges, he discovered a flaw in the Linux kernel network protocol stack. By sending carefully crafted packets from inside a microVM, he achieved three types of attacks: leaking host memory over the network, crashing the host, and executing code on the host.

The memory-leak attack was verified on Vercel's production sandbox — host memory appeared in packets the guest sent over the internet, and as long as the guest kept sending data, the leak could continue indefinitely. The crash and code-execution attacks were reproduced on the researcher's own KVM and Firecracker machines configured to match Vercel Sandbox. By sending two specific packets, the researcher could bring down the host, shutting down every sandbox running on it; exploiting the same flaw, he could also run commands on the host with full administrator privileges, completely breaking through the sandbox isolation boundary.

microVM and Firecracker: A microVM is a lightweight virtual machine that, compared with a traditional VM, strips away a large amount of unnecessary device emulation and keeps only the minimal I/O channels, compressing boot time to milliseconds and memory overhead to a few MB. AWS's open-source Firecracker is the most mainstream implementation of this approach: it uses KVM to provide hardware virtualization of CPU and memory, then replaces the full QEMU device tree with a minimal user-space device model (virtio-net, virtio-block, etc.). Each microVM has its own kernel and address space, which is precisely the foundation on which cloud providers isolate customer workloads. For this very reason, the attack surface is concentrated in KVM, the virtio device backends, and the network path between guest and host — and Paulos Yibelo's attack started exactly from the guest's network protocol stack, following the data path of the virtual NIC to reach the host.

Why This Vulnerability Affects the Entire Cloud Computing Industry

Nearly every major cloud provider isolates customer workloads at the same layer of the Linux kernel, which means any kernel flaw is a shared-infrastructure risk. After being notified, Vercel immediately worked with the researcher to understand and mitigate the vulnerability, while coordinating with AWS and other industry partners to prioritize a fix. The researcher also contacted kernel maintainers and helped create candidate patches; the fix is currently under private review, with a CVE number pending. Vercel chose to publicly disclose the existence of the vulnerability because it had already been publicly disclosed elsewhere. This incident reveals a core paradox of cloud security: the efficiency advantages brought by a shared kernel layer are also the root of a single point of failure.

Why a Kernel Flaw Equals Cross-Tenant Risk: In a multi-tenant architecture, isolation usually has two layers — hardware virtualization (KVM/CPU's VMX/SVM) provides strong isolation of memory and privilege levels, while shared subsystems such as networking, storage, and memory reclamation reuse the same host kernel code. Once a function in the kernel that handles guest data (for example, network packet parsing, page table operations, or a device backend) has a flaw, an attacker can — without any privileges — construct input from the guest side to trigger unauthorized reads or writes on the host. This differs from a simple "jailbreak": its consequence is not escaping your own virtual machine, but directly reading or corrupting data of other tenants on the same host. So the "shared kernel layer" is both the cornerstone of efficient cloud scheduling and a single point of failure shared across the entire industry — which also explains why Vercel had to coordinate a fix with AWS and kernel maintainers rather than simply patching it on its own.

Cross-Tenant Disk Snapshot Restoration: A Classic Lesson in Trust Boundaries

A Control Plane Fooled by Guest Data

Among the reports submitted on the first day of the challenge, Vercel considers one of the most representative to have found a trust-boundary violation in the snapshot restoration mechanism. When you take a snapshot of a sandbox, the control plane needs to record where the snapshot data is stored: {storage_url, size, checksum}. The problem is that this information comes from software running inside the guest, yet the service on the host treats it as authoritative data.

The researcher intercepted and rewrote the snapshot response inside his own sandbox, swapping the snapshot storage objects of two different accounts. The result: restoring "your" snapshot would actually load another account's entire filesystem. The researcher verified that the two accounts could read and write each other's files, confirmed the result with hashes, and preserved the test resources for Vercel to independently reproduce.

Control Plane and Trust Boundaries: The control plane refers to the set of services in a cloud platform responsible for scheduling, orchestration, authentication, snapshots, and lifecycle management. It is separated from the data plane — which actually runs customer workloads — in both responsibilities and privileges. In a multi-tenant system, the trust boundary is the line crossed from the "untrusted" side to the "trusted" side: any software running inside a guest is inherently on the untrusted side, because its behavior is entirely controlled by the tenant. The classic violation pattern is when a service on the trusted side treats data returned by the untrusted side as authoritative fact and accepts it directly. The snapshot vulnerability is exactly this: the storage service on the host treated the {storage_url, size, checksum} reported by the guest as instructions it had issued itself, effectively handing key decisions — which object to access, whether to verify, whose filesystem to read — to the tenant. The correct approach is that all data crossing the boundary must be re-derived on the server side, or accepted only after being signed with a key inaccessible to the guest.

Attack Limitations and Fix

This attack has a key limitation: to swap targeting a specific victim, one needs to know that victim's internal snapshot storage key — a 96-bit random identifier the platform generates for each snapshot, never exposed in the API. This key exists only inside the victim's own sandbox. The researcher had two accounts, which was the precondition for proving feasibility; there is no evidence that a stranger could launch an attack against other tenants. Vercel still treated it as a priority fix, because "a boundary that depends on a secret staying secret is not a real boundary."

You may not have noticed that Trail of Bits flagged the same root cause in its independent assessment, showing that this finding is real, important, and discoverable from two completely 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 was moved from a guest-reachable environment to a host-side service; and storage paths are scoped per project and use strictly validated URLs.

Trail of Bits White-Box Review: Architectural Conclusions and Three Structural Improvements

The Virtualization Boundary Was Rated Reliable

Before launching the public bounty program, Vercel conducted an internal security assessment and invited two engineers from Trail of Bits to evaluate its security architecture. Trail of Bits invested four engineer-weeks digging into the source code, had full repository access and two enterprise test teams, and delivered 20 findings, each tested, confirmed, and cited to specific code.

Their architectural review concluded that the virtualization boundary is reliable. Each sandbox runs in its own Firecracker microVM with a dedicated guest kernel, and the device model is deliberately kept small. No guest shares a running kernel with the host or with other tenants. This conclusion provided independent validation of Vercel's sandbox isolation model and explains why none of the 1,285 reports found anyone accessing customer data.

Three Structural Recommendations

On this basis, Trail of Bits offered three structural recommendations, all of which Vercel has implemented:

Eliminate all trust in the guest. The control plane previously accepted values returned by software inside the microVM, and these values are inherently tenant input. Now any data crossing the boundary must be derived server-side or signed with a key the guest cannot obtain.

Unify policy decisions. Egress network policy was previously scattered across multiple subsystems, each independently parsing the same network policy, and the results were not always consistent. Now each data type uses one canonical routine, each decision is owned by one component, and connections are revalidated when policy changes.

Assume the next zero-day will eventually arrive. Vercel hardened the protections around every sandbox: keeping host kernels up to date, disabling nested virtualization, and using Firecracker's jailer to run each microVM process with restricted privileges and isolate it from the rest of the host.

Egress Network Policy and the Jailer: Egress network policy determines which addresses a sandbox can actively connect to, and is a key gate preventing the guest from exfiltrating data or scanning the internal network. When the same policy is distributed across multiple subsystems and parsed independently, the system becomes highly prone to inconsistency — one path allows it while another denies it — and an attacker only needs to find the most permissive path to bypass it. Unifying this into a single canonical routine and a single decision component essentially eliminates this kind of "policy drift." As for Firecracker's jailer, it is a wrapper that starts the microVM process with least privilege: before creating the sandbox, it places the process into a cgroup and network namespace, drops privileges to a non-privileged user, discards excess capability bits, and limits the visible filesystem scope. That way, even if a microVM process is compromised, the attacker only gets a heavily constrained sandbox — which is exactly how "assume the next zero-day will eventually arrive" is put into practice.

The New Paradigm of Security Research Behind 1,285 Reports

Breaking Down the Data

The 1,285 reports received within two weeks break down as follows: 877 duplicates, 319 not applicable, 57 valid, and 32 informational. Among the valid findings, there were 1 critical, 5 high, 9 medium, 42 low, and 32 informational findings verified. The medium, low, and informational findings were mostly small policy boundary gaps, such as firewall rule behavior differing from documentation, or a field trusting the guest too much.

Vercel specifically noted that this volume of reports was possible because researchers now conduct vulnerability hunting at AI speed. The heterogeneity of report sources was also impressive — some focused on Linux namespaces aimed directly at the kernel boundary, some attacked network policy, and others explored areas Vercel itself had not thought of.

Internal Findings and External Bounties Complement Each Other

Not all findings came from outside. Vercel intern Marcos Hernandez discovered cross-tenant data leakage in the Linux device-mapper storage layer: any sandbox could read disk blocks reclaimed from deleted sandboxes. This finding, together with Trail of Bits' review and the external bounty program, forms Vercel's multi-layered security validation system — internal assessment provides depth, white-box review provides an architectural perspective, and the public bounty brings unimagined diversity and scale.

Implications for the Cloud Security Industry

The value of Vercel's challenge goes beyond security improvements for a single product. It validated a pattern: even after internal assessment and white-box review, a public bounty program can still uncover issues both of the former missed — the snapshot trust-boundary vulnerability is the best example, with Trail of Bits independently flagging the same root cause, but an external researcher finding it via a completely different path.

At the same time, the discovery of the Linux kernel zero-day reminds us that the underlying foundation of cloud security remains fragile. When the entire industry's multi-tenant isolation depends on the same layer of kernel code, a single flaw can affect every provider. Vercel's decision to coordinate the fix with AWS and other industry partners and to publicly disclose the existence of the vulnerability provides a reference template for managing the risks of shared infrastructure.

For development teams building sandbox environments, the biggest technical lesson of this challenge is perhaps that concise principle: never trust any value returned by the guest. Every piece of data the control plane accepts from a microVM is potentially tenant input and needs to be re-derived server-side or signed with an unreachable key. This principle applies not only to virtual-machine-level isolation but also to any scenario in a multi-tenant architecture that crosses a trust boundary.

One-line Summary

Vercel's million-dollar sandbox challenge received 1,285 reports in two weeks and uncovered a Linux kernel zero-day affecting the entire industry.

Paragraph Summary

Vercel launched a million-dollar sandbox escape challenge, receiving 1,285 reports within two weeks and paying out $242,000 in bounties, ultimately uncovering a Linux kernel zero-day affecting nearly every major cloud provider. Researcher Paulos Yibelo crafted packets inside a microVM with no special privileges, achieving three attacks: host memory leak, host crash, and host code execution, with the memory leak already verified in production. Another key report revealed that the snapshot restoration mechanism trusted storage information returned by the guest, leading to cross-tenant filesystem loading. Trail of Bits' four-engineer-week white-box review confirmed the virtualization boundary is reliable and proposed three structural recommendations: eliminate trust in the guest, unify policy decisions, and assume a zero-day will eventually arrive. The article ultimately distills the core principle for multi-tenant architectures: "never trust any value returned by the guest."