Vercel's April 2026 breach started with Context.ai, a third-party AI tool.
An attacker compromised the tool's Google Workspace OAuth app, hijacked a Vercel employee's account, then accessed environment variables that weren't marked "sensitive." Vercel is now asking customers to rotate those secrets, even though they were classified as non-sensitive.
Vercel contacted the limited subset of customers whose credentials were confirmed compromised. But the broader lesson applies to any organization: a third-party OAuth compromise can cascade into internal systems fast. Vercel called the attacker "highly sophisticated" based on their speed and detailed knowledge of Vercel's systems.
Investigate, Then Rotate
Assume any related secret is at risk until you've investigated it. Identify every exposed credential, check where it's used, and confirm whether it's active or already abused. Then revoke or rotate it, redeploy, and verify dependent services.
Vercel's guidance is direct: use the "sensitive" flag for environment variables that contain API keys, tokens, database credentials, or signing keys. Sensitive variables are stored in a way that prevents them from being read.
Scan Your Environment Variables
If you're a Vercel customer responding to this incident, start by pulling your environment variables locally and scanning them for exposed secrets.
Pull your environment variables for each project:
vercel env pull
Then scan the file with GitGuardian:
ggshield secret scan path .env.local
Dwayne McDaniel
Dwayne McDaniel
GitGuardian will identify which variables contain valid secrets, such as API keys, tokens, or database credentials, signing keys. This gives you a prioritized list of what to rotate first. You can also scan across multiple projects by pulling each environment file and scanning the directory:
ggshield secret scan path .Once you've identified exposed secrets, rotate them in your upstream services (like AWS, Stripe, or database providers) before updating the values in Vercel.
Harden Controls for the Next Incident
Vercel published the following guidance for customers:
- Review the activity log for your account and environments for suspicious activity. You can review activity logs in the dashboard or via the CLI.
- Review and rotate environment variables. If any of your environment variables contain secrets (API keys, tokens, database credentials, signing keys) that were not marked as sensitive, those values should be treated as potentially exposed and rotated as a priority.
- Take advantage of the sensitive environment variables feature going forward, so that secret values are protected from being read in the future.
- Investigate recent deployments for unexpected or suspicious looking deployments. If in doubt, delete any deployments in question.
- Ensure that Deployment Protection is set to Standard at a minimum.
- Rotate your Deployment Protection tokens, if set.
