A Bug Bounty That Broke Its Own Triage Process
Vercel ran a two-week, public bug bounty against Vercel Sandbox — the Firecracker microVM environment the company uses to isolate untrusted, AI-agent-generated code — from August 18 to September 1, 2026. By the time the window closed, the company had a result it didn't fully plan for: two real Linux kernel bugs surfaced in its host boundary, and the report volume from AI-assisted researchers arrived faster than any human triage team could keep up with.
The program combined black-box testing from the public HackerOne researcher community with white-box testing from Trail of Bits, and offered rewards of up to $50,000 for a single report demonstrating cross-tenant data access.
What Happened
| Attribute | Detail |
|---|---|
| Target | Vercel Sandbox (Firecracker microVM isolation for untrusted/AI-agent code) |
| Program window | August 18 – September 1, 2026 (two weeks) |
| Testers | HackerOne public researchers (black box) + Trail of Bits (white box) |
| Reward pool | Up to $1,000,000 USD, max $50,000 per report |
| Reports received | 1,285 in two weeks |
| Validated findings | 1 Critical, 7 High, 15 Medium, 49 Low, 19 Informative |
| Committed payouts | Approximately $325,000 |
| Kernel bugs confirmed | Two, in the Linux kernel's networking stack |
| Customer data accessed | None reported |
The architecture being tested is deliberately layered: each Vercel Sandbox runs on a bare-metal EC2 host, with a dedicated Firecracker microVM and guest kernel per sandbox, and a Linux container running the actual workload inside that microVM. Vercel treats the microVM — not the container — as the real security boundary, and its threat model assumes the code running inside is fully hostile, with root access inside the container and full kernel access inside the microVM.
The Kernel Flaws
Researchers confirmed two independent defects in the Linux kernel's networking stack reachable from inside the sandboxed guest kernel:
- One that leaks memory from the host kernel
- One that deterministically crashes the host
Neither bug allowed an attacker to read or modify another tenant's data, and Vercel says no researcher successfully accessed real customer data during the program. Both issues remain under private review pending formal CVE assignment, so specific technical root causes and affected kernel version ranges have not been published yet. Given the scope of the challenge, the flaws sit in the guest kernel's networking code path that stays reachable even after container-level namespace restrictions — which is exactly the layer Vercel had asked researchers to attack, since namespace-only escapes to the guest kernel weren't considered in-scope "wins" on their own.
The AI-Assisted Research Angle
The headline number is less the kernel bugs themselves and more how fast they — and everything else — showed up. 1,285 reports in fourteen days is an enormous volume for a single bug bounty program, and Vercel has pointed to AI-assisted tooling as the reason: researchers increasingly use AI agents to explore attack surface, generate proof-of-concept exploits, and draft reports at a pace no team of human hackers could match unassisted.
That volume is also a preview of a broader industry problem. As AI coding and research assistants make vulnerability discovery cheaper and faster, the bottleneck in bug bounty programs shifts from "finding bugs" to "verifying and triaging thousands of reports of wildly varying quality" — many of them AI-generated, not all of them valid, and some effectively indistinguishable from each other except for wording.
Vercel's Response: Automating Triage
Vercel's initial plan was straightforward human review. According to the company, that approach stopped scaling past roughly 50 reports — nowhere near the 1,285 the program ultimately received.
In response, Vercel built an AI triage agent on top of its own Eve agent framework to work through the backlog. The agent:
- Reads each incoming report
- Checks it against the program's scope and policy rules
- Hunts for duplicate reports describing the same underlying root cause
- Executes the researcher's proof-of-concept to verify the claimed impact
Vercel has said it plans to open-source this triage tooling, which would let other bug bounty programs facing the same AI-driven volume spike adopt a similar automated first pass rather than building one from scratch.
Why This Matters
This story sits at the intersection of two trends security teams are watching closely:
- AI is changing the economics of vulnerability research. When AI assistance lets a single researcher generate a high volume of plausible, tested reports, bug bounty programs built around manual human triage break down — not because the bugs aren't real, but because the intake process can't keep pace. Programs that don't adapt their triage pipeline risk drowning in report volume regardless of whether they're getting better security signal out of it.
- Sandbox and microVM isolation is only as strong as the host kernel underneath it. Vercel Sandbox, like many "run untrusted AI-agent code safely" products, leans on Firecracker's microVM boundary rather than container namespaces alone. That's a stronger boundary in general, but this challenge is a reminder that the guest Linux kernel's own attack surface — networking code included — is still very much in scope for a determined attacker, AI-assisted or not. As more infrastructure providers race to offer sandboxes for autonomous AI agents, the security of that guest-kernel boundary becomes a shared dependency for the whole AI-agent ecosystem, not just one vendor's product.
Vercel says every technique surfaced during the two-week window is being folded back into hardening the sandbox boundary, and the company has committed to continuing triage on outstanding reports through the weeks following the program's close.