What happened in the Vercel April 2026 breach?

On April 19, 2026, Vercel disclosed that attackers gained unauthorized access to internal systems. The attack originated through Context.ai, a third-party AI tool used by a Vercel employee. The attacker used a compromised OAuth integration to take over the employee's Google Workspace account, then pivoted into Vercel environments where they accessed environment variables that were not marked as sensitive.

Were Vercel environment variables marked as sensitive affected?

According to Vercel, environment variables marked as sensitive are stored in a manner that prevents them from being read, and Vercel currently has no evidence that those values were accessed. However, environment variables that were not flagged as sensitive may have been exposed. If you store API keys, database credentials, or tokens in non-sensitive environment variables, you should rotate them immediately.

Is Next.js affected by the Vercel breach?

Vercel has confirmed that Next.js, Turbopack, and their open-source projects remain safe and were not compromised. However, if you deploy Next.js applications on Vercel and store secrets in environment variables, those secrets may have been exposed regardless of the framework you use.

Who is ShinyHunters and what are they claiming?

ShinyHunters is a well-known threat actor group with a history of large-scale data thefts. They claimed responsibility for the breach and posted on hacking forums offering to sell access keys, source code, employee records, and database contents for $2 million. However, their claims are unverified and it is not confirmed whether they were actually behind the attack.

Should I rotate my credentials even if Vercel has not contacted me?

Yes. Vercel initially contacted a limited subset of customers whose credentials were confirmed compromised, but the full scope of the breach is still under investigation. If you have any secrets stored in Vercel environment variables that are not marked as sensitive, rotate them now. The cost of rotating credentials is low compared to the risk of a compromised API key or database connection string.

The Vercel Breach: What Happened, Who Is Affected, and What You Should Do Right Now

On April 19, 2026, Vercel published a security bulletin confirming that attackers gained unauthorized access to internal Vercel systems. The breach originated through a compromised third-party AI tool and may have exposed environment variables, API keys, and deployment data for an unknown number of customers.

This is not a theoretical vulnerability. Attackers are actively claiming to sell stolen data. If you deploy applications on Vercel, you need to take action today.

Here is what happened, who is affected, and exactly what you should do.

What Happened

The attack chain started outside Vercel entirely.

Step 1: A third-party AI tool was compromised. An AI platform called Context.ai was breached. Context.ai had a Google Workspace OAuth integration that granted access to employee accounts at organizations using the tool.

Step 2: The attacker pivoted through OAuth. The compromised OAuth application (Client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com) was used to take over a Vercel employee's Google Workspace account. This is not a password theft. It is an OAuth token hijack: the attacker gained access through an existing authorized integration that the employee had previously approved.

Step 3: Internal Vercel systems were accessed. With the employee's Google Workspace account under their control, the attacker accessed some Vercel internal environments and was able to read environment variables that were not marked as "sensitive."

Step 4: Data exfiltration. A threat actor claiming to be "ShinyHunters" posted on a hacking forum offering to sell access keys, source code, employee records (~580 entries), and database contents from Vercel. The asking price: $2 million with a $500,000 initial payment in Bitcoin.

What Was Exposed

Confirmed by Vercel:

Unauthorized access to internal systems occurred
A limited subset of customer credentials were compromised
Environment variables not marked as "sensitive" were accessible

Claimed by the attacker (unverified):

API keys, NPM tokens, and GitHub OAuth tokens
Access to Vercel's internal Linear project management system
Employee records including names, emails, and account statuses
Source code and database contents
Access to internal deployments

Not affected (according to Vercel):

Environment variables marked as "sensitive" show no evidence of access
Next.js, Turbopack, and Vercel's open-source projects remain uncompromised
Vercel's services remained operational throughout

Why This Matters Beyond Vercel

This breach is a textbook example of a supply chain attack through a third-party AI tool, and it highlights a risk that is growing across the industry.

The AI Tool Supply Chain Problem

A Vercel employee authorized Context.ai to access their Google Workspace account. That is a normal workflow in 2026: AI tools request OAuth access to read emails, calendars, and documents to provide contextual assistance.

The problem is that every OAuth integration you approve becomes a potential entry point. When Context.ai was compromised, every organization with an active OAuth grant was at risk. Not just Vercel.

If anyone in your organization uses AI tools with OAuth access to Google Workspace, Microsoft 365, GitHub, or Slack, you share this same attack surface.

The Environment Variable Problem

The distinction between "sensitive" and "non-sensitive" environment variables in Vercel is important.

Vercel's sensitive environment variable feature stores values in a way that prevents them from being read after they are set. They can only be used by the build and runtime environment, never displayed in the dashboard or accessed through the API.

Regular environment variables are readable. If the attacker had access to Vercel's internal systems, they could read any environment variable that was not explicitly marked as sensitive.

Many developers store database connection strings, API keys, payment processor secrets, and authentication signing keys in regular environment variables. If you have done this on Vercel, those secrets may now be compromised.

The OAuth Token Problem

The attacker reportedly gained access to GitHub tokens associated with Vercel users. A compromised GitHub token is not just a login credential. Depending on the token's scope, an attacker could:

Clone private repositories that were never deployed to Vercel
Read CI/CD configurations that contain additional secrets
Map your entire codebase architecture
With write access: inject code, plant backdoors, or poison your supply chain

What You Should Do Right Now

1. Check for the Compromised OAuth App

Search your Google Workspace admin console for the compromised Context.ai OAuth application:

Go to Security > Access and data control > API controls
Search for Client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
If found, revoke access immediately and investigate what data it had access to

Even if you do not find this specific app, audit all third-party OAuth applications connected to your workspace.

2. Rotate Credentials by Priority

Rotate immediately (Tier 0):

All GitHub Personal Access Tokens (both fine-grained and classic)
All Vercel environment variables containing secrets
Kill existing GitHub sessions

Rotate today (Tier 1):

Payment processor secret keys (Stripe sk_live_*, Adyen, Braintree)
Authentication signing secrets (AUTH_SECRET, NEXTAUTH_SECRET, JWT keys)
Database connection strings with write access
Cloud provider keys (AWS IAM, GCP service accounts, Azure secrets)
Webhook signing secrets

Rotate this week (Tier 2):

Third-party SaaS API keys (analytics, email, SMS, CRM)
OAuth client secrets for your own applications
SMTP credentials
Feature flag provider keys

3. Enable Sensitive Environment Variables

After rotating your secrets, re-add them as sensitive environment variables in Vercel. This ensures they cannot be read through the dashboard or API after they are set.

Go to your project settings, remove the old environment variable, and create a new one with the "Sensitive" toggle enabled.

4. Audit Your GitHub Integration

Revoke and re-authorize Vercel's GitHub integration:

Go to GitHub Settings > Applications > Authorized OAuth Apps
Find the Vercel integration and revoke access
Re-authorize with the minimum repository scope needed

While you are there, review all authorized OAuth apps. Remove anything you do not actively use.

5. Review Deployments and Build Logs

Check your Vercel deployment history for:

Deployments that do not correspond to commits you recognize
Build logs containing accidentally printed credentials
Changes to vercel.json, next.config.js, or framework configurations
Unexpected rewrites or redirects

6. Audit Your Lock Files and Dependencies

If the attacker had access to GitHub tokens with write permissions, check for tampering:

Diff package-lock.json or pnpm-lock.yaml against a known-good commit
Look for unexpected changes to package.json scripts (postinstall, prepare, preinstall)
Check .github/workflows/*.yml for new run steps or unpinned actions
Review vercel.json for new rewrites or build command changes

7. Check Downstream Systems

If your Vercel environment variables included credentials for other services, check those services for unauthorized activity:

AWS CloudTrail: Unusual API calls, GetObject bursts, CreateUser events
Database audit logs: Unusual queries, large exports, connections from unexpected IPs
Stripe/payment logs: Unauthorized transfers, new API key generation
Auth provider logs: Impossible-travel logins, unintended password resets

If You Publish NPM Packages

This deserves its own section. If any of your NPM publish tokens were stored in Vercel environment variables, an attacker could publish malicious versions of your packages.

Check immediately:

Run npm view <package> time --json to verify no unexpected versions were published
Run npm owner ls <package> to check for unauthorized maintainers
Revoke and rotate your NPM token at npmjs.com
Audit your recent publish history

If you find unauthorized publishes, deprecate (do not unpublish) the compromised versions and report to security@npmjs.com.

The Bigger Lesson: AI Tools Are Attack Surface

This breach was not caused by a vulnerability in Vercel's code. It was caused by a third-party AI tool that had been granted OAuth access to an employee's account.

Every AI tool, browser extension, and SaaS integration that has OAuth access to your identity provider is a potential entry point for attackers. The breach path was: AI tool > OAuth token > Google Workspace > Vercel internal systems > customer data.

This is the new reality of supply chain attacks. The attack surface is no longer just your dependencies and your code. It is every tool that has been granted access to your organization's identity layer.

What to do about it:

Audit all OAuth applications connected to your Google Workspace, Microsoft 365, and GitHub organization
Restrict new OAuth app installations to an allowlist rather than allowing any employee to approve them
Review the scopes granted to each application. Does that AI assistant really need access to Gmail and Google Drive?
Implement quarterly reviews of all authorized integrations

Vercel's Response

Vercel published their security bulletin on April 19, 2026. They have:

Contacted the limited subset of customers with confirmed credential compromise
Engaged external incident response experts
Notified law enforcement
Published indicators of compromise (IOCs) to help the community identify potential malicious activity
Confirmed that Next.js and their open-source projects were not affected

The investigation is ongoing. Vercel has committed to updating their bulletin as new information becomes available.

Protect Your Web Application

The Vercel breach is a reminder that your application's security posture depends on more than your own code. Third-party platforms, OAuth integrations, and environment variable management all contribute to your attack surface.

Run a free StackShield scan on your application to check for exposed secrets, misconfigured security headers, and other externally visible vulnerabilities. Whether you deploy on Vercel, AWS, or anywhere else, knowing what is visible from the outside is the first step to fixing it.