If you have projects running on Vercel with API keys, database credentials, tokens, or signing keys stored as environment variables, you need to read this. Not tomorrow. Now.

What Actually Happened

Vercel's official bulletin confirmed that attackers gained unauthorised access to internal systems. The breach did not start directly at Vercel. It started at a small third-party AI tool called Context.ai, whose Google Workspace OAuth app was compromised. That single compromised OAuth connection gave attackers a foothold in a Vercel employee's account and, from there, into Vercel's internal systems.

Internal tools, including Linear and GitHub, were accessed. A limited subset of customers had their data potentially exposed. Vercel has contacted those customers directly, but here is the important part: Vercel is recommending that all customers, not just the ones directly notified, review and rotate their environment variables immediately.

A threat actor going by the alias ShinyHunters claimed to be selling Vercel's data on BreachForums, including employee accounts, source code, database data, GitHub tokens, and npm tokens. Given that Vercel owns Next.js, security researchers warned that this could potentially escalate into a supply chain attack affecting every developer who uses Next.js. As of now, Vercel's CEO, Guillermo Rauch, has stated that their supply chain, including Next.js, Turbopack, and other open-source projects, remains safe. But the situation is still developing.

The Good News and the Bad News

Here is where things stand clearly.

The good news is that environment variables marked as sensitive in Vercel are encrypted and stored separately. Vercel currently has no evidence that sensitive variables were accessed. If you used Vercel's sensitive environment variable feature, your encrypted secrets are likely safe.

The bad news: Standard environment variables, the ones not marked as sensitive, were potentially exposed. Those are API keys, database passwords, tokens, and signing keys that millions of developers store in plain text in their Vercel projects without realising the difference.

If you have ever set an environment variable in Vercel and did not check the sensitive box, treat that secret as compromised until you rotate it.

Why This Attack Vector Is So Dangerous

This breach did not happen because Vercel wrote bad code. It happened because an employee used a third-party tool with Google Workspace OAuth access. That tool got compromised. That OAuth token provided enough access to pivot into Vercel's internal systems.

This pattern is happening with increasing frequency. Every third-party app you connect to your Google Workspace, GitHub organisation, or cloud accounts is a potential entry point. You are only as secure as the least secure tool in your OAuth app list.

Security researcher John Tuckner put it well: if you are responding to this breach by looking at your OAuth apps for one specific ID, also export the full list while you are there. Spend time asking yourself which scopes you have allowed and whether you recognise every service.

What You Should Do Right Now

Here is a practical checklist based on Vercel's official guidance:

Step 1: Identify your exposed variables

Log in to your Vercel dashboard. Go to Settings, then Environment Variables for each project. Any variable not marked as sensitive is potentially at risk. Make a list.

Step 2: Generate new credentials at the source

For each exposed variable, go to the third-party service, whether that is AWS, Stripe, Supabase, a database provider, or anything else, and generate a new credential. Do not delete or invalidate the old one yet.

Step 3: Update Vercel first, then redeploy

Update the environment variable in Vercel with the new value. Mark it as sensitive this time. Then redeploy your project. This step is critical: Vercel environment variables are baked in at build time for many frameworks. Changing the variable without redeploying keeps the old secret alive in your running deployment.

Step 4: Invalidate the old credential

Only after your redeployment succeeds and you have verified everything works, go back to the third-party service and invalidate the old credential. Doing this before redeploying will break your production application.

Step 5: Repeat for every project

If you have team-level environment variables shared across multiple projects, you need to redeploy every project that uses that variable before invalidating the old credential. Miss one project, revoke the old key, and that project goes down.

Step 6: Audit your OAuth apps

Go to your Google Workspace Admin Console and review every connected OAuth app. Remove anything you do not recognise or no longer use. Do the same for your GitHub organisation settings. This breach started with an OAuth app that had too much access.

Priority Order for Rotation

Not all secrets carry the same risk. Rotate in this order:

Rotate today without question:

• Payment processor keys (Stripe, Razorpay, Braintree)
• Database connection strings with write access
• Authentication, signing secrets, and JWT keys
• Cloud provider keys (AWS IAM, GCP service accounts)
• Webhook signing secrets

Rotate this week:

• Third-party API keys for any service with user data access
• OAuth client secrets
• Email provider credentials
• Analytics and monitoring tokens

Check and confirm sensitivity settings:

• Any remaining environment variable that is not already marked as sensitive in Vercel

The Lesson That Goes Beyond This Breach

The Vercel breach is not an isolated incident. March 2026 alone saw five major supply chain incidents in 12 days. The pattern is the same every time: attackers find the weakest link in a chain of connected services and use it to pivot to higher-value targets.

Every developer tool you connect to your cloud accounts via OAuth is a potential entry point. Most developers connect tools once, give them broad permissions, and never revisit the list. That is the real vulnerability.

A few practices that would have reduced the blast radius of this breach:

Mark every secret as sensitive in Vercel. It encrypts the value and hides it from the dashboard. It costs nothing and takes seconds per variable.

Rotate secrets on a schedule, not just after incidents. Most teams only rotate after a breach. By then, it is too late.

Audit OAuth app permissions regularly. Remove anything you do not actively use. Scope permissions to only what each app actually needs.

Mirror your rotation to CI/CD pipelines. If a secret was also stored in GitHub Actions, CircleCI, or another pipeline, rotate it there as well. The Vercel variable is not the only place it lives.

Final Thoughts

Vercel acted quickly, disclosed the incident publicly, and confirmed its supply chain remains intact as of now. That is the right response. But the breach happened because of an extremely common pattern: too much OAuth access granted to too many tools, with no regular review.

If you use Vercel, rotate your non-sensitive secrets today. Mark everything as sensitive going forward. And while you are in your dashboard, spend 10 minutes auditing every OAuth app connected to your Google Workspace and GitHub organisation.

The breach may be contained. The lesson should not be.