Vercel

Getting Started

Test Plan

Platform Assets

• Users can sign up for a free account through vercel.com
• Please use your hacker email alias when registering test accounts ([email protected])
• Create your own projects and deployments to test against. Do not test against deployments, projects, or teams you do not own

Open source assets

• Use standard development environments and officially documented setup procedures
• Test against the latest stable release unless you are investigating a specific version issue
• Reproduce locally. Do not run proof-of-concept testing or active exploitation against live Vercel services, Vercel-owned production websites or APIs, deployed customer environments, CI/CD in Vercel-maintained repositories, or Vercel-owned infrastructure

Resources

• Vercel Documentation
• Open source project documentation: Next.js, Nuxt, SWR, Svelte, Turborepo, AI SDK, Vercel CLI, Nitro, Eve, chat, workflow

Focus Areas

The Vercel platform establishes trust boundaries between us, our customers, and 3rd parties. As such we are particularly interested in reports that cover:

• Infrastructure & Platform Control Bypasses
  • Especially RCE on Vercel Infrastructure
  • And SSRFs with demonstrable impact against Vercel Infrastructure
• Tenant Resource Authn / Authz Breaches
  • Especially critical security boundary providing products like Vercel Firewall and Vercel Sandbox
• Account and/or Session Takeover
• RCE (Remote Code Execution) in Our Open Source Web Frameworks

For open source projects, the vulnerability classes of most interest for each project (and which areas are lower priority or require novelty to be considered) are published in: {F6792416}.

Scope

Security is complex & nuanced and it is impossible to set perfect guidelines.

For open source projects, specific policies around scope in the codebase (usually in SECURITY.md) must be respected.

See the “Out of Scope” section for what is considered out of scope or not substantive for a submission.

Asset classes

Classifying open source and platform findings

Which class a finding falls into sets the bounty band:

• A vulnerability in framework or library code that would affect any operator running it anywhere is an open source finding, even where you reproduced it on a Vercel deployment.
• A vulnerability that depends on Vercel's hosting, build pipeline, edge network, or tenancy model is a platform finding, even where the affected code is open source.

Submission Requirements

We actively want to work with researchers who find real, impactful vulnerabilities and write clear, actionable reports. When a report demonstrates a genuine finding with a working exploit chain and a well-articulated impact, we take it seriously and compensate accordingly. The quality of a report matters: a concise, well-reasoned submission with a strong PoC will always be prioritized over volume.

Reports that appear to be generated by AI tools without manual validation, contain hallucinated or unverified claims, or consist of scanner output without a working exploit will be marked as 'Not Applicable'. Researchers with a pattern of submitting such reports will be flagged and deprioritized in the program.

Every report must include a working proof-of-concept that demonstrates the complete exploit chain. This means:

• A functional PoC that an independent reviewer can reproduce
• Demonstrated end-to-end impact: not just the entry point, but what an attacker concretely reads, writes, executes, or extracts
• Platform: reproducible on the current production platform
• Open source: reproducible on a stable release. Canary or RC releases are in scope only where no stable release has superseded the affected version range; issues present only in a superseded canary or RC are out of scope

Reports will not be considered for bounty if they consist of:

• Scanner or static analysis output without a working exploit chain
• AI or LLM tool findings that have not been manually verified with a functional PoC
• Theoretical chains where one or more steps require unrealistic conditions
• Issues that require the attacker to already have privileged access to the affected team, project, or environment
• Vulnerable or outdated dependency reports without a demonstrated exploit chain. Flagging that a dependency has a CVE is not a valid submission on its own. We may consider a report that demonstrates a complete chain showing exploitable impact in the context of the affected project, where there is no existing open issue or pull request already tracking the fix
• Public zero-day vulnerabilities that have had an official patch for less than one month. These are awarded on a case-by-case basis.

What to include in your report

• Affected URL: for platform findings, the URL where the issue reproduces. For open source findings, a GitHub permalink to the affected file and line (for example, github.com/vercel/next.js/blob/<commit>/packages/next/src/server/<file>.ts#L42).
• Affected Version(s): required for open source findings, the affected version or version range of the published package. If this does not apply (e.g. for a platform finding), enter N/A. If this is not included for an open source asset, the report will be moved to the Needs More Info state automatically.
• Proof-of-concept artifact, per the asset class below.
  • Platform findings: A screenshot or video demonstrating the issue. Screen recordings should be unedited and show the full reproduction path. Screenshots should cover each step, not just the end result
  • Vercel Sandbox findings: A zip file containing working proof-of-concept code, demonstrated against a live sandbox. Screenshots or video, where they help. Also include in the report:
    • Vercel Team ID used during testing (team_…)
    • Vercel Project ID used during testing (prj_…)
    • Vercel Sandbox ID where the issue was reproduced (sbx_…)
  • Open Source findings: A zip file containing working proof-of-concept code that demonstrates the issue in the affected version(s). Screenshots or video, where they help.
  • Note: If the affected asset or PoC artifact are not included or attached within the report, the submission will be automatically moved to the Needs More Info state until the necessary info is provided.
  • In cases where the required artifact is not feasible (for example race conditions, blind SSRF confirmed via callback, or timing-dependent issues), raw request and response captures, interaction logs, minimal test cases, or detailed reproduction steps may be accepted at Vercel's discretion and not without Vercel's approval.
• Your hacker email alias must be visible in the account used for the proof of concept, so we can verify the testing was performed against assets you own.
• Suggestions for patches or mitigation are optional but can warrant a bonus at Vercel's discretion.

Severity Assessment

We use CVSS 4.0 scoring with adjustments for:

• Real-world exploitability in typical deployment scenarios
• Asset tier (platform, open source Tier 1, open source Tier 2)
• Impact on customers and their end users
• Ease of exploitation and attack complexity
• Default vs. non-default configuration requirements
• Severity reduction in cases reliant on beta, experimental, or preview features

Bonus Modifiers

A finding may be eligible for a bonus on top of the base award. All bonuses are granted at Vercel's discretion and are not guaranteed. The following may qualify a finding for a bonus:

• Exceptional impact: For example, novel attack chains affecting default configurations, cross-tenant compromise, vulnerabilities that compromise customer data at scale, or findings that represent a meaningful advance over prior public research.
• High-quality reports: Well-structured reports with clear, reproducible analysis and demonstrated impact, particularly those that include suggested patches or mitigation.

Out of Scope

Core Ineligible Findings are out of scope.

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug.

For open source projects, specific policies around scope in the codebase (usually in SECURITY.md) must also be respected.

Do not submit AI generated reports without first reviewing and confirming real impact and verifying a working proof-of-concept. What we mean by real impact means demonstrable breaches or data impact / exfil in production for Vercel.

Universal Exclusions (Includes, but not limited to:)

• Third-party customer applications and deployments hosted on Vercel
• Third-party services, even where reachable under an in-scope domain
• Templates, examples, starter projects, and documentation code snippets
• Third-party dependencies, unless misused by Vercel
• Injection issues in third-party source code not maintained by Vercel
• End of Life (EoL) or deprecated products and features
• Community infrastructure (Discord, GitHub Discussions, etc.)
• Personal websites and blogs of Vercel employees
• Issues requiring destructive testing
• Content modification where content is intentionally editable
• Issues that can only be exploited when the underlying platform (browser, server runtime) is compromised
• Denial of service, including via excessive legitimate use. Denial of service vulnerabilities affecting OSS maintained by Vercel and in scope of this bug bounty program will be accepted, but testing and reproduction of these vulnerabilities must never be made on the Vercel platform.
• Cosmetic issues, UI/UX inconsistencies, or display problems
• Attacks requiring MITM
• Cross-Site Request Forgery (CSRF) on unauthenticated forms
• Vulnerabilities only affecting users of outdated or unpatched browsers [less than 2 stable versions behind the latest released stable version]
• Metric manipulation (activity counts, statistics) without financial or data access impact
• Username or profile validation issues that do not enable impersonation or a security bypass
• Logical issues with no demonstrated security or significant financial impact
• Financial loss of a nominal amount
• Resource mapping (network, files, and similar)
• Attacks with pre-privileged attackers
• Attacks based on malicious upstream input from servers/APIs/MCPs etc., unless the product is explicitly meant to protect against malicious 3rd party input

Open Source Exclusions

• Issues based on demo/reference code included in the open source repo
• Issues based on esoteric, weak, or misconfigured settings / configuration
• Issues based on vulnerable application code
• Hardening/Defense In Depth/”Insufficient Fix” Issues, unless for critical vulns like RCE
• Local attacks against development runtimes like `next dev`,`vercel dev` unless there is a demonstrated remote attack with reasonable pre-conditions
• Using untrusted user content without sanitization in places that are not explicitly sanitized by the framework
• Build-time tooling (webpack, babel, terser)
• Issues in provider packages that are not in the core SDK, report those to the relevant provider's security program
• SWC: Rust standard library or LLVM vulnerabilities
• Skills: malicious or deceptive third-party skills, and scanner alerts about skill content, where the skills infrastructure itself is not vulnerable

Sandbox-Specific Exclusions

{F7010553} contains detailed instructions on Sandbox.

• Container namespace escapes that only reach the Firecracker guest OS (PID, mount, net, disk, or device namespaces). Namespaces are a developer-experience feature, not the security boundary
• Denial of service against your own sandbox
• Vulnerabilities in third-party websites that reflect credential-brokering headers back to the sandbox. Credential retrieval is in scope only when the headers are exposed through a Vercel-side defect, not when an external destination echoes them
• Behavior the Sandbox docs direct operators to configure differently — for example combining a domain allowlist with subnets.allow, or relying on a CIDR-only policy to restrict DNS, which the Sandbox firewall docs warn against
• Already-public Firecracker or other software component CVEs reported as a version match. A CVE being present in a version does not mean it is exploitable here. If you weaponize one, it is in scope: a public upstream vulnerability you drive to a real escape to the host or to another tenant on a live sandbox is eligible, and is paid at the impact you demonstrate
• Custom-kernel or custom-VMM attacks that require a kernel or Firecracker build an operator cannot supply
• Build-phase Dockerfile / Containerfile build environment issues, and Vercel Container Registry issues
• The @vercel/sandbox SDK and CLI client code. The server-side sandbox control plane API these clients call is in scope

Known Issues

Some of our open source projects will call out known issues in their SECURITY.md that are not eligible for vulnerability findings.

Rules of Engagement

• Test only what you own: Only interact with accounts, projects, teams, and deployments you own, or where you have explicit written permission from the owner.
• No production testing for open source findings: reproduce open source vulnerabilities locally. Do not run proof-of-concept testing or active exploitation against live Vercel services, Vercel-owned production websites or APIs, deployed customer environments, CI/CD in Vercel-maintained repositories, or Vercel-owned infrastructure
• Detailed reports required: Please provide detailed reports with reproducible steps and the proof-of-concept artifact required for your asset class. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
• One vulnerability per report: Submit one vulnerability per report unless you need to chain vulnerabilities to provide impact.
• Duplicates: When duplicates occur, we award the first valid report (provided it can be fully reproduced).
• Internal duplicates: a report may be closed as a duplicate of a finding already recorded internally, including one not listed on this page and findings we have chosen not to fix. We will explain the basis when we do
• Root cause consolidation: multiple vulnerabilities caused by one underlying issue will be awarded one bounty
  • Patched versions (open source): where a previously rolled-out patch works on the submitted affected version, the report is a duplicate. If the patch does not work on that version, it may be considered for a bounty at Vercel's discretion
• No social engineering: Social engineering (e.g., phishing, vishing, smishing) against Vercel employees, customers, or researchers is prohibited.
• Good faith testing: Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of services.
• Cross-tenant testing: always use two accounts you own (one attacker, one victim) and reproduce the cross-tenant access entirely between them. If that is impossible because the issue appears to depend on a target you do not control, stop after a single confirmation: record what you observed, redact third-party data, and report. Never enumerate, dump, persist, or further explore another tenant's data. The goal is to prove the boundary broke, not to maximize impact. A clean, minimal confirmation pays the same as a noisy one
• Do not access more data than necessary to prove the vulnerability. Where you can demonstrate cross-tenant access, a single confirmation is sufficient — do not enumerate, retain, or exfiltrate another tenant's data.
• Stop immediately if you encounter personal data or secrets; do not download, retain, or share it; redact it from your report.
• Do not attempt to achieve or maintain persistence on any Vercel-owned system.
• Scanner rate limits: Security scanners must be limited to 5 queries per second (QPS) when testing against Vercel domains to avoid service disruption.
• Do not damage, disrupt, access, or modify data on any system you are not authorized to test.
• All testing must not violate any law or compromise data you do not own.
• Do not make any threats against Vercel or HackerOne staff.
• Do not share or publish details of a report without explicit written permission from Vercel staff.
• Open source contributions: any pull requests or contributions related to a report should be shared with Vercel staff through private forks unless you have explicit permission otherwise

Disclosure & Confidentiality Policy

Participation in this program is conditional on confidentiality obligations. By submitting a report, you agree to the following:

• Confidential Information includes all, but is not limited to, all vulnerability reports, proof-of-concept code, communications with Vercel, program documentation, and any related materials shared or generated through your participation.
• You may only use Confidential Information for the purpose of participating in this program.
• You may not disclose Confidential Information to any third party without Vercel's express written consent, except to authorized Vercel employees, or contractors who have a legitimate need to know and are bound by equivalent confidentiality obligations.
• You must keep all Confidential Information secure and promptly notify Vercel if you become aware of a breach.
• You must securely delete Confidential Information within 30 days of Vercel's written request, except where retention is required for legal or compliance reasons.
• Confidentiality obligations last for two (2) years from the date of disclosure, even if this program ends or your participation ceases.

Disclosure of vulnerabilities, including resolved issues, will be at Vercel's discretion and coordinated with the researcher. Vercel aims to post advisories on applicable repositories after appropriate remediation and coordination periods.

Researchers must respect all applicable laws and the community standards outlined in the Vercel Code of Conduct. Any behavior that violates this Code may result in disqualification from the program and forfeiture of bounty eligibility.

Researchers must also follow HackerOne's disclosure guidelines. Where there is any conflict between those guidelines and this Policy, this Policy prevails.

Breach of these obligations will result in disqualification from the program and forfeiture of eligibility for rewards.

CVEs (Open Source)

This section applies to open source findings only. Platform vulnerabilities are not in distributable code and are not eligible for a CVE.

CVEs will be provided at Vercel's discretion, but vulnerabilities must meet the following minimum requirements for consideration:

• Lead to action on a Tier 1 repository with an adjusted CVSS score of at least 3.8
• Lead to action on a Tier 2 repository with an adjusted CVSS score of at least 7.0
• Be present in distributable code (npm, PyPI, or similar)
• Not be reliant on an experimental feature or development mode

Reports given a CVE will be made public 30 days after the CVE's publication, subject to variability at Vercel's discretion.

Ineligible Participants

• Vercel employees and contractors (past or present)
• Maintainers and contributors of Vercel-sponsored open source projects (past or present)
• Immediate family members of Vercel employees
• Individuals involved in the vulnerability discovery or fix, including as part of a paid Vercel engagement such as a pentest
• HackerOne staff working on this program

Support

• HackerOne Support
• [email protected]

Thank you for helping keep Vercel and our customers safe!