The attacker-controlled input was not a prompt but the snapshot metadata returned by code inside a sandbox. Before the fix, the restore control plane accepted guest-supplied storage location, size and checksum as though the guest could attest which object belonged to the current project. The researcher replaced that metadata and recovered files owned by a…
Inspect the ClaimsCase · DiggingBeagle record
Guest-selected Vercel Sandbox snapshot storage could cross account boundaries
Vercel snapshot restore trusted guest-provided storage metadata and could restore another researcher-owned account’s files.
Scope
Two investigator-controlled Vercel Sandbox accounts in the disclosed demonstration, with knowledge of the other snapshot storage identifier. Host-side project binding reportedly fixed within one week; random third-party snapshot discovery not shown.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Impact
- Band 3 of 4
- Evidence
- Grade A
- Remediation
- fixed reported
- AI role
- AGAINST AI
Basis and provenance
Vercel reports that the researcher preserved test resources for its reproduction and Trail of Bits independently identified the same host-trust root cause. The vendor states host-owned snapshots and project-scoped object binding shipped within a week. This is a strong bounded cross-account demonstration, not arbitrary victim enumeration.
Impact basis: An investigator swapped guest-reported snapshot metadata between two controlled accounts, then read and modified the other account's restored filesystem. Knowing an unexposed random 96-bit snapshot identifier was a prerequisite for targeting a stranger.
Assessed Oct 19, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-VERCEL-SANDBOX-SNAPSHOT-SWAP · Vercel: findings from the one-million-dollar Sandbox challenge
At a glance
An identifier cannot substitute for project authorization, even when it has high entropy. After disclosure, Vercel reported moving snapshot creation to the host and binding storage objects to projects.
Read the implicationsThe reproduction required the target snapshot key, a 96-bit random identifier not made available by the public API. No arbitrary stranger-to-victim recovery path or customer data access was shown. The fix reportedly shipped within one week.
Limits and uncertaintyFull account
The attacker-controlled input was not a prompt but the snapshot metadata returned by code inside a sandbox. Before the fix, the restore control plane accepted guest-supplied storage location, size and checksum as though the guest could attest which object belonged to the current project. The researcher replaced that metadata and recovered files owned by a second account they also controlled.
A randomly generated storage key still imposed an important practical prerequisite. The public API did not reveal arbitrary other users' 96-bit snapshot identifiers, so the demonstration does not establish that an attacker could choose a stranger's snapshot at will. It does establish that the restore operation failed to check ownership once a usable identifier had been supplied. This is a violation of storage authorization, not evidence of a general cryptographic guessing failure.
Vercel reported a fix that moved snapshot creation to trusted host logic and scoped stored objects to projects. To verify the correction, a cross-project restore must fail even when the caller knows a valid foreign snapshot identifier; changing the entropy of the identifier alone would not correct the authorization model.
Claims & evidence
CLM-VERCEL-SANDBOX-SNAPSHOT-SWAPAn investigator changed snapshot metadata returned from a guest so that restoring a snapshot under one account materialized files owned by a different account they also controlled.supported
Basis: reported finding
- supportsVercel: findings from the one-million-dollar Sandbox challengeprimary disclosure
Cross-tenant disk snapshot restore (with limits); fix shipped within one week
Implications
An identifier cannot substitute for project authorization, even when it has high entropy. After disclosure, Vercel reported moving snapshot creation to the host and binding storage objects to projects.
Controls and mitigations
- Bind snapshot ownership and project authorization at the host before restoration, and verify the storage object rather than trusting guest-supplied metadata.
Unknowns and contradictions
- The reproduction required the target snapshot key, a 96-bit random identifier not made available by the public API. No arbitrary stranger-to-victim recovery path or customer data access was shown. The fix reportedly shipped within one week.
Sources and citation
Material revision history
- Oct 19, 2026 · Published version · first publication · revision 174
- Oct 19, 2026 · Canonical change recorded · material revision · revision 175Public fields changed: assessment_profile