The Vercel Breach: How It Actually Happened, and What You Need to Do Right Now

April 20, 2026
Based on confirmed details from Vercel's security bulletin, CEO Guillermo Rauch's update, and community incident response documentation.

The short version

Vercel got breached. The entry point was not a zero-day in Next.js. It was not a misconfigured S3 bucket. It was a third-party AI tool that a Vercel employee was using. Context.ai got compromised first, and that became the ladder the attacker climbed into Vercel's internal systems.

If you run anything on Vercel, you need to rotate your secrets today. Not tomorrow. Now.

Here is everything that is confirmed, everything that is still alleged, and exactly what to do.

How it escalated: the full chain

Step 1: Context.ai gets breached
Context.ai is an enterprise AI platform. It is the kind of tool that ingests your company's internal docs, workflows, and institutional knowledge to build custom AI agents for your team.

A Vercel employee was using it. This is standard stuff since lots of companies use tools like this now to move fast.

What made it dangerous was that Context.ai had been integrated with the employee's Google Workspace account with deployment-level OAuth scopes. This meant it had deep access. It did not just have read access to a few docs. It had enough foothold to move laterally once the platform itself was compromised.

The attacker breached Context.ai first. That gave them the employee's credentials and Google Workspace session.

Step 2: Google Workspace pivot
With the employee's Google Workspace account compromised, the attacker now had an authenticated identity inside Vercel's organizational systems.

From here, they moved to enumeration. Vercel CEO Guillermo Rauch described the attacker as "highly sophisticated based on their operational velocity and detailed understanding of Vercel's systems" and specifically noted they were likely AI-accelerated in how fast they moved through the environment.

This is important. The attacker did not sit around. They moved fast, systematically, and clearly knew what they were looking for.

Step 3: Environment variable enumeration
Vercel encrypts environment variables at rest. The ones you have flagged as "sensitive" in the dashboard are stored in a way that prevents them from being read even with internal access.

The problem was that non-sensitive env vars were enumerable once the attacker was inside.

When you are rapidly iterating and vibe coding your Next.js and TypeScript projects, you probably do not mark everything as sensitive. Why would you? DATABASE_URL, NEXT_PUBLIC_API_KEY, STRIPE_WEBHOOK_SECRET, and GITHUB_TOKEN often sit in regular env vars because nobody thought someone would be inside Vercel's internal systems reading them.

Now someone was.

Step 4: GitHub and Linear integrations
Community reporting (notably from developer Theo Browne on X) points to Vercel's GitHub and Linear integrations taking the brunt of the access.

This is the part that should concern you most if you are a developer.

GitHub integration means the attacker potentially had access to:

Repository access tokens
Deployment keys
Webhook secrets
In some cases, the ability to read private repo contents

Linear integration means they could access:

Issue data including customer names and bug details
Secrets that developers paste into Linear tickets during debugging. This is extremely common. Someone pastes a Postgres connection string into a Linear comment to share context. That comment is now potentially in attacker hands.

Step 5: BreachForums listing
Someone claiming to be ShinyHunters, a well-known extortion group, posted on BreachForums offering the stolen data for $2M. The listing claimed to include access keys, source code, internal DB data, employee accounts, GitHub tokens, npm tokens, and internal deployment credentials.

Important caveat is that actual members of ShinyHunters have denied involvement to BleepingComputer. The attacker may be using the name for credibility. Vercel and Mandiant have not confirmed the specific data classes in the listing. They only confirmed that internal systems were accessed and some customer data was impacted.

Treat the listing as directionally accurate for rotation purposes. Do not cite it as confirmed in customer communications.

What is confirmed vs. what is alleged

Confirmed by Vercel and Guillermo Rauch:

Unauthorized access to internal systems via Context.ai breach leading to a Google Workspace pivot.
Non-sensitive environment variables were enumerable.
A "limited subset" of customers was directly impacted and has been contacted.
Next.js, Turbopack, and open source projects are safe. There are no malicious artifacts in the release pipeline.
Google Mandiant is engaged in the response.
Law enforcement has been notified.

Reported by community and attackers (not confirmed by Vercel):

GitHub and Linear integrations specifically hit.
$2M BreachForums listing with specific data classes.
ShinyHunters attribution (disputed by the group itself).
Full scope of data exfiltrated.

The thing nobody is saying clearly enough

This breach was not about Vercel's security being weak in the traditional sense.

It was a supply chain attack through an AI tool.

A legitimate employee, using a legitimate enterprise tool, with legitimate OAuth scopes. The entire chain collapsed when the weakest link (the third-party tool) got compromised.

This is the pattern for the next 5 years of security incidents. You are not just trusting your infrastructure provider. You are trusting every tool that has OAuth access to your infrastructure provider. The number of those tools has exploded in the AI era.

Every AI productivity tool you have given Google Workspace or GitHub OAuth to is a potential entry point into your entire stack. This includes Notion AI, Cursor, Context.ai, or any enterprise AI agent.

Most teams have not thought about this. Start thinking about it.

What to do right now: the actual checklist

Priority 1: Rotate everything that touched Vercel (do this today)
Work through these in order:

Database credentials: Find any DATABASE_URL, POSTGRES_URL, MONGO_URI, or similar variables stored as non-sensitive env vars on Vercel. Rotate the DB password, update the env var, and redeploy. Check your DB access logs for unusual queries during April 1 to 19.
GitHub tokens: Go to GitHub > Settings > Developer Settings > Personal Access Tokens. Revoke any tokens that had Vercel access. Check your GitHub audit log (Settings > Security > Audit Log) for unusual OAuth app authorizations, new SSH keys, or unexpected clones of private repos.
NPM tokens: Go to npmjs.com > Access Tokens. Revoke any tokens used in Vercel CI/CD. Check npm audit log for unexpected publishes.
Third-party API keys: Stripe, Sendgrid, Resend, Twilio, OpenAI, Anthropic. Rotate all of them if they are stored as env vars. Most providers let you create a new key and deprecate the old one without downtime.
OAuth tokens: For any OAuth integrations you have connected through Vercel, revoke and reconnect them.

Priority 2: Check your Linear workspace
Grep your Linear workspace for common secret patterns. Developers paste these into tickets constantly:

AKIA (AWS access keys)
sk_live_ (Stripe live keys)
ghp_ or ghs_ (GitHub tokens)
npm_ (npm tokens)
eyJ (JWT tokens that may contain signing secrets)
-----BEGIN (private keys)

Anything found should be rotated immediately regardless of how old the ticket is.

Priority 3: Audit your Google Workspace and Cloud OAuth access
This is where the actual breach started. You need to lock down what third-party apps can read your data. Go through every tool that has Google Workspace or Google Cloud OAuth access connected to your organization.

In Google Workspace: Go to the Google Admin console. Navigate to Menu > Security > Access and data control > API controls. Click "Manage App Access." Review every configured app. Ask yourself if these tools actually need the scopes they have. Revoke anything you do not actively need and downgrade scopes where possible.
Check Workspace Logs: While in the Admin console, go to Menu > Reporting > Audit and investigation > OAuth log events. Filter for the last 30 days to see exactly which users granted access to new third-party apps.
In Google Cloud Console: Go to APIs & Services > OAuth consent screen. Review the apps authorized for your projects. Check your "Authorized domains" and ensure no rogue apps have been granted broad Cloud access.
If any tool got breached tomorrow, ask yourself what an attacker could reach from it.

Priority 4: Mark sensitive env vars as sensitive
Vercel has a "sensitive environment variable" feature that encrypts these in a way that prevents them from being enumerated even with internal access. If you were not using this before, use it now for everything that matters.

Priority 5: Check your deployment pipeline
If you have GitHub Actions or other CI/CD that touches Vercel:

Review recent workflow runs for anything unexpected.
Check if any workflow secrets were used in unexpected contexts.
Rotate any VERCEL_TOKEN values in your CI.

The bigger lesson

The Vercel breach is a preview of how most serious breaches will happen in the next few years.

They will not happen through brute force. They will not happen through an unpatched vulnerability in your own code. They will happen through the expanding web of tools with OAuth access to your infrastructure. Each one is a potential entry point, and most of them have more access than they actually need.

The developer tooling ecosystem has grown enormously in the last two years, especially AI tools. Every one of them that you have connected to your GitHub, your Google Workspace, or your Vercel is now part of your attack surface.

Most teams have not audited this. Most do not even have a complete list of what has OAuth access to what.

That list is what you need. Start building it. And rotate your secrets today.