Vercel’s April 2026 breach exposed a critical gap in how deployment platforms handle OAuth tokens. The attack vector was unusual: a Roblox cheat tool and an AI coding assistant. The damage was concrete: OAuth tokens stored as environment variables leaked across project boundaries, giving attackers access to customer repositories and deployment pipelines.
This incident differs from typical credential compromise or misconfiguration vulnerabilities. It reveals structural problems in how serverless platforms scope secrets and how third-party integrations interact with build environments.
The Attack Pattern
According to Trend Micro’s analysis, the breach involved a supply-chain compromise through two distinct tools. A malicious Roblox cheat tool, distributed through underground forums, targeted OAuth tokens stored as environment variables in Vercel projects. The tool specifically harvested VERCEL_TOKEN, GITHUB_TOKEN, GITLAB_TOKEN, and BITBUCKET_TOKEN from developer machines and CI/CD environments.
An AI coding assistant with access to the compromised environment amplified the damage. The assistant’s logging and telemetry mechanisms exposed additional tokens. Attackers used the harvested OAuth tokens to access repositories and deployment configurations belonging to other Vercel customers who shared the same OAuth authorization scope.
The breach persisted for approximately three weeks before Vercel detected anomalous API usage patterns and began token revocation.
The Root Cause: User-Scoped Tokens in Project Environments
The cross-project leakage occurred because of a fundamental architectural decision in how Vercel (and similar platforms) handle OAuth tokens.
When you connect a GitHub repository to Vercel, the platform requests an OAuth token from GitHub. This token is scoped to your GitHub user account, not to a specific Vercel project. Vercel stores this token in its infrastructure and injects it into build environments for any project you create that needs repository access.
If an attacker compromises one Vercel project (through malicious dependencies, supply-chain attacks, or vulnerable build plugins), they can extract the OAuth token from that project’s environment variables. Because the token is user-scoped, it grants access to all repositories the user can access, not just the repository linked to the compromised project.
How the Leak Propagated
- Shared token storage: Vercel stores OAuth tokens at the user account level, not the project level.
- Environment variable injection: During builds, Vercel injects these tokens into the build container’s environment variables (
process.env.GITHUB_TOKEN). - No project isolation: Multiple projects belonging to the same user receive the same OAuth token in their build environments.
- Third-party tool access: Build plugins, AI assistants, and analytics tools running in the build environment can read all environment variables.
User-scoped tokens enable seamless multi-project workflows. But they also mean that a breach in one project can cascade across all projects that share the same user credentials.
Environment Variable Scoping in Deployment Platforms
Serverless platforms inject environment variables into build and runtime environments. These variables include API keys for third-party services, database connection strings, and OAuth tokens for repository access.
The scoping problem is architectural. Most platforms scope environment variables at the project level, but OAuth tokens often carry organization-wide or account-wide permissions. A GitHub OAuth token might grant access to multiple repositories or organizations. If that token leaks from one project, the blast radius extends beyond the compromised project boundary.
How Vercel Handles OAuth Tokens
Vercel stores OAuth tokens to enable automatic deployments from GitHub, GitLab, and Bitbucket. When you connect a repository, Vercel requests an OAuth token. The specific scopes vary by provider, but typically include repository read/write access and webhook management.
These tokens are stored in Vercel’s infrastructure and made available to build environments. The tokens are scoped to the user who authorized the integration, not the project. If an attacker compromises one project, they can extract tokens that grant access to all repositories the authorizing user can access.
Trust Boundaries and Third-Party Integrations
The Vercel breach highlights a fundamental tension in serverless platforms: convenience versus isolation.
Convenience: OAuth tokens enable one-click deployments. Developers do not need to manually configure webhooks or manage SSH keys.
Isolation: OAuth tokens cross project boundaries. A token issued for one project can access resources in another project if the user has the right permissions.
| Trust Boundary | What It Protects | Why It Fails |
|---|---|---|
| Project-level environment variables | Secrets scoped to a single project | OAuth tokens carry user-level permissions that span multiple projects |
| User-level OAuth tokens | Automatic deployments without manual setup | Platforms inject the same token into all projects owned by the user |
| Build environment sandboxing | Code execution isolation | Third-party tools (AI assistants, analytics) can read environment variables and transmit them externally |
| Secret rotation policies | Stale tokens after user revocation | Most OAuth providers issue long-lived tokens with no automatic expiration |
How AI Coding Tools Exfiltrate Secrets
AI coding assistants like GitHub Copilot, Cursor, and Codeium have access to your codebase and environment during development. Some also run in CI/CD pipelines or serverless build environments.
In the Vercel breach, the AI tool likely operated as a build-time plugin or development environment extension. The attack pattern is consistent with tools that access environment variables during code analysis and transmit them to backend APIs for context enrichment. The tool’s logging mechanism likely captured the full environment variable set, including OAuth tokens, and sent them to a third-party analytics endpoint that the attackers had compromised.
Sandboxing AI Tools in Build Environments
To prevent secret exfiltration, AI tools should run in a restricted sandbox with no network access to untrusted endpoints, read-only access to a filtered subset of environment variables, and comprehensive audit logs.
General mitigation patterns include running third-party tools in isolated containers with network policies that whitelist only trusted domains, dropping privileges to non-root users, and using proxy services to filter outbound traffic. Production implementations require separate execution contexts with explicit permission boundaries for any tool that participates in the build process.
Secret Rotation and Observability
The Vercel breach persisted because OAuth tokens were long-lived and not monitored for unusual activity. Most platforms do not rotate OAuth tokens automatically. GitHub tokens, for example, do not expire unless explicitly revoked (as of 2026).
Detection Patterns
You can detect OAuth token misuse by monitoring:
- Geographic anomalies: Tokens used from unexpected IP ranges or countries.
- Scope escalation: Tokens used to access repositories or organizations outside the original authorization scope.
- Rate limit violations: Tokens making an unusually high number of API calls.
- Concurrent usage: Tokens used from multiple locations simultaneously.
GitHub, GitLab, and Bitbucket provide audit logs for OAuth token usage. You can query these logs via API and alert on suspicious patterns.
Detection systems need to account for VPNs, NAT, and legitimate concurrent usage (e.g., CI/CD and local development). GitHub’s audit log API requires enterprise-level access and does not expose IP addresses for all event types.
Deployment Shape and Failure Modes
Serverless platforms abstract away infrastructure, but they introduce new failure modes:
- Environment variable leakage: Secrets exposed in logs, error messages, or third-party integrations.
- Token scope creep: OAuth tokens with broader permissions than necessary.
- Cross-project contamination: Secrets from one project accessible in another project’s build environment.
- Third-party plugin risk: Build plugins or integrations with access to environment variables.
Mitigation Strategies
- Use short-lived tokens: Rotate OAuth tokens every 24 hours or less.
- Scope tokens narrowly: Request only the permissions you need (e.g.,
repo:statusinstead ofrepo). - Separate build and runtime secrets: Use different tokens for CI/CD and production.
- Audit third-party integrations: Review permissions for all plugins and tools in your build pipeline.
- Monitor token usage: Alert on geographic anomalies, scope escalation, and rate limit violations.
Technical Verdict
Recommended for:
- Teams that need fast iteration and automatic deployments.
- Small teams without dedicated DevOps resources.
- Projects where you can implement compensating controls (token rotation, monitoring) to mitigate environment variable leakage risk.
Not recommended for:
- Applications handling sensitive data (PII, financial records, health information).
- Environments requiring fine-grained control over secret management and access policies.
- Projects integrating third-party tools that require access to environment variables and cannot be sandboxed.
If you use a serverless platform, treat OAuth tokens as high-value secrets. Rotate them frequently, monitor their usage, and sandbox third-party integrations. The Vercel breach shows that environment variables are not just configuration. They are a supply-chain attack surface.