Vercel Breach Traced to Context.ai Supply Chain Compromise — Rotate Your Environment Variables Now

Introduction

Vercel, the hosting platform behind Next.js, has disclosed a security incident that exposed internal systems and customer environment variables. The breach did not start at Vercel — it started at Context.ai, a third-party AI productivity tool that a Vercel employee had connected to their corporate Google Workspace account with "Allow All" permissions. A threat actor using the ShinyHunters name is now offering the stolen data on BreachForums for $2 million.

What Happened

The intrusion chain is a case study in modern OAuth supply chain abuse. A Context.ai employee was infected with Lumma Stealer malware, reportedly after downloading Roblox "auto-farm" scripts on a personal device that also held corporate credentials. The infostealer harvested their Google Workspace tokens, which the attacker then used to pivot into Context.ai's own infrastructure.

From there, the attacker pulled the OAuth tokens of every user who had granted Context.ai access to their Google accounts. One of those users was a Vercel employee who had signed up for Context.ai's "AI Office Suite" consumer product using their corporate Google identity and approved broad Workspace scopes. With that token in hand, the attacker took over the employee's Vercel Google Workspace account and reached internal Vercel systems.

Inside Vercel, the attacker accessed environment variables that customers had not explicitly marked as "sensitive." Variables flagged as sensitive (which are encrypted at rest) were not exposed according to Vercel's investigation. Still, plenty of real credentials end up in non-sensitive variables: database URLs, webhook secrets, API keys for third parties, and deployment tokens.

Google's Threat Intelligence Group has suggested the actor claiming to be ShinyHunters may in fact be an impostor borrowing the group's notoriety. Regardless, the stolen data is real, it is being offered for sale, and Vercel customers need to act.

Known indicators of compromise published by Vercel:

  • Malicious OAuth app ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  • Malicious Chrome extension ID: omddlmnhcofjbnbflmjginpjjblphbgk

Why It Matters

This is exactly the kind of incident the industry has been warning about — one compromised employee at an AI startup, granted sweeping OAuth scopes over a customer's Workspace, ending in the breach of a major cloud platform. The blast radius is huge because Vercel customers' non-sensitive environment variables often include credentials that, in their own context, are very sensitive indeed. Every production deployment on Vercel should now treat those credentials as potentially leaked.

It also illustrates why "Allow All" OAuth prompts are so dangerous. One employee clicking through a consent screen for an AI product effectively granted an unknown third party the keys to a core platform.

Who Is Affected

  • Any Vercel customer with environment variables not explicitly marked as "sensitive"
  • Vercel customers using Deployment Protection tokens that were not rotated recently
  • Organizations whose employees connected Context.ai to their corporate Google Workspace
  • Downstream consumers of any service hosted on Vercel that relied on leaked credentials

How to Protect Yourself

Rotate all non-sensitive Vercel environment variables immediately. Use the Vercel CLI to list and update them per project:

vercel env ls production
vercel env rm <VARIABLE_NAME> production
vercel env add <VARIABLE_NAME> production

For Team accounts, enforce the "Sensitive" flag on every secret going forward. The Vercel API lets you audit this in bulk:

curl -H "Authorization: Bearer $VERCEL_TOKEN" \
  "https://api.vercel.com/v10/projects/<PROJECT_ID>/env"; | \
  jq '.envs[] | select(.type != "encrypted") | {key, type}'

Rotate Deployment Protection tokens if you use bypass URLs or protection bypass for automation:

vercel project update --deployment-protection=standard

Audit your Google Workspace for the malicious OAuth app. As a Workspace admin:

Admin console → Security → API controls → App access control → Manage third-party app access
Search for Client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
Revoke access and block the app

Or via the Admin SDK API, list third-party token grants:

gcloud auth application-default print-access-token
curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
  "https://admin.googleapis.com/admin/directory/v1/users/<USER>/tokens";

Harden your OAuth posture. Move Google Workspace to "Restrict third-party app access" mode so users cannot grant new apps without admin review:

Admin console → Security → API controls → Restrict user access → Access is restricted

Rotate anything downstream of those environment variables — database credentials, third-party API keys (Stripe, Twilio, SendGrid, etc.), webhook secrets, and OAuth client secrets for any app whose configuration was stored as a non-sensitive Vercel env var.

Source