Vercel's $1M Bounty Concludes: 1,285 Reports, $242K in Payouts, and a Linux Kernel 0day

A Sandbox Attack-and-Defense Experiment Spanning Several Months

Vercel launched a bounty program with a total pool of $1 million, with a single goal: escape the Vercel Sandbox. According to officially published figures, the campaign ultimately received 1,285 vulnerability reports, paid out a cumulative $242,000 in bounties, and uncovered a Linux kernel zero-day vulnerability. More critically, no report indicated that customer data had been compromised.

This was not an ordinary bug bounty event. Vercel Sandbox is the isolated execution environment it provides for AI-generated code, allowing developers to run untrusted code without affecting the host system. Offering a bounty to escape the sandbox is, in essence, testing the security boundary of the entire isolation layer.

Why a Sandbox-Escape Bounty Is Worth Watching

AI coding tools are bringing large amounts of automatically generated code into production environments, and the execution security of that code depends on the reliability of the sandbox. If the sandbox can be escaped, an attacker can penetrate from the isolated environment to the host system, obtain sensitive data, or take control of infrastructure. By offering a real-money bounty for escaping it, Vercel effectively conducted a public stress test of its own security architecture.

Sandbox and Sandbox Escape

A sandbox is an isolated execution environment that runs untrusted code by restricting the system resources a process can access (files, network, devices, kernel interfaces, etc.). Common implementations include virtualization-based microVMs (such as Firecracker), container-based namespace isolation, and language-level runtime sandboxes. Sandbox escape refers to an attacker breaking through this isolation layer to gain host system privileges or access other tenants' data from within the controlled environment. Escapes typically exploit three classes of flaws: sandbox misconfiguration (such as overly permissive seccomp policies), vulnerabilities in the sandbox monitor itself (the VMM or runtime), and vulnerabilities in the underlying kernel or hardware interfaces. In AI code execution scenarios, an escape means that malicious code generated by a model or submitted by a third party could compromise the entire infrastructure.

The Attack-and-Defense Signals Behind the Numbers

Three numbers are worth examining separately.

1,285 Reports: High Interest, Low Hit Rate

More than a thousand reports show that the security research community has strong interest in Vercel Sandbox, but the vast majority of reports did not achieve an escape. This indirectly reflects that the sandbox's baseline defenses are effective—a large number of attempts were blocked, and only a few paths could potentially reach deeper flaws.

$242,000 in Bounties: A Tiered Reward Structure

A total of $242,000 against a $1 million pool indicates that only some high-severity vulnerabilities ultimately reached the top reward tier. Vercel did not disclose the specific amount for each vulnerability, but a Linux kernel zero-day usually corresponds to the top tier, with the remaining payouts distributed across multiple medium- and low-severity findings.

The Linux Kernel Zero-Day: Exposing the Sandbox's Underlying Dependencies

The most closely watched item is the Linux kernel zero-day vulnerability. Sandbox isolation often relies on kernel-level mechanisms (namespaces, cgroups, seccomp, etc.), and vulnerabilities in the kernel itself can directly collapse the isolation boundary. Finding a zero-day is not surprising in itself—any isolation solution that depends on the Linux kernel faces this layer of risk—but the fact that a public bounty could uncover a zero-day shows that Vercel's sandbox attack surface indeed reaches down to the system's foundations.

Linux Kernel Isolation Mechanisms and Zero-Day Risk

Container-based sandbox isolation mainly relies on several sets of mechanisms provided by the Linux kernel: namespaces isolate process views, cgroups limit resource usage, seccomp filters system calls, capabilities partition privileges, and user namespaces enable privilege mapping. Together these mechanisms form the isolation boundary, but the security of that boundary ultimately depends on the kernel implementation itself. A kernel zero-day is a vulnerability that has not yet been publicly disclosed and has no patch, allowing attackers to exploit it before the vendor knows about it. Several well-known escape vulnerabilities in history (such as Dirty COW, Dirty Pipe, and the overlayfs privilege-escalation series) all stemmed from defects in kernel subsystems. Because all sandboxes based on a shared kernel are exposed to the same attack surface, a single kernel zero-day can affect many isolation solutions at once—which is why such findings are regarded as the highest severity tier.

Implications for AI Infrastructure Security

Vercel's bounty offers the industry a reference sample.

Sandbox Security Is the Infrastructure of AI Applications

AI applications rely heavily on code execution sandboxes to run model-generated code. Sandbox escape is no longer merely a traditional cloud security topic; it is a prerequisite for whether AI products can be deployed safely. By proactively offering a bounty, Vercel is effectively acknowledging that this layer needs continuous external scrutiny.

A Zero-Day Exposure Does Not Mean Product Failure

Finding a Linux kernel zero-day does not mean Vercel Sandbox's design has a fundamental flaw. On the contrary, being able to locate and fix a kernel-level issue through a bounty program demonstrates security response capability. What matters is whether the vulnerability is patched in time and whether any customer data was affected—the official statement says the latter is zero.

The Costs and Benefits of the Bounty Model

$242,000 in exchange for a kernel zero-day and over a thousand security signals is a reasonable investment for an infrastructure vendor. A public bounty can leverage external researchers to cover attack paths that an internal team would struggle to exhaustively enumerate, and it also signals security investment to customers. But bounties have limits: they reward reportable vulnerabilities and cannot cover every attack surface, so continuous security auditing remains necessary.

How Bug Bounties Work

A bug bounty is a mechanism by which vendors publicly invite security researchers to test their systems and pay rewards based on vulnerability severity. Compared with internal penetration testing, a bounty can reach a broader group of researchers and attack ideas, but it has clear limits: rewards target only reproducible, reportable vulnerabilities and cannot measure undiscovered attack surfaces; researcher incentives may skew toward easy-to-find medium- and low-severity issues; and a public campaign may also expose system information prematurely. The industry commonly uses scoring systems such as CVSS to define reward tiers, with high-severity issues and zero-days usually corresponding to the highest payouts. Vercel setting a $1 million total pool and actually paying $242,000 reflects a model of paying by tier based on actual findings, rather than consuming the entire fixed budget.

Will the Industry Follow Suit?

Vercel's bounty results may encourage more AI infrastructure vendors to publicly challenge their sandbox security. For developers, when choosing a code execution sandbox, they should look not only at performance and ease of use but also at whether the vendor has a public security verification mechanism.

The final takeaway from this bounty can be summed up as: the sandbox was not easily broken, but the underlying risks are real; no data was leaked, but security investment cannot stop.