Vercel via Context.ai: The AI OAuth Supply Chain Playbook for SMBs

The shortest version of the Vercel story: a Context.ai employee downloaded a Roblox auto-farm script in February that carried a Lumma Stealer payload. The infostealer pulled OAuth tokens off the laptop. One of those tokens belonged to a Vercel engineer who had connected the Context.ai AI Office Suite to their corporate Google Workspace with "Allow All" permissions. Two months later, on April 19, the attackers used that single token to walk into Vercel's enterprise Workspace, pivot into Vercel's internal systems, and enumerate customer environment variables. ShinyHunters claimed the haul, dropped employee data and tokens on BreachForums, and asked for $2 million.

Nothing about that chain was exotic. The malware was commodity. The OAuth flow was the same one every consumer SaaS app uses. The "Allow All" click was the same click every employee makes thirty times a year. And the dwell time was two months — long enough that nothing in any standard SIEM rule was going to flag it.

This is the supply chain attack pattern that has overtaken almost every other story in 2025-2026. It is also the one most SMBs have no defense against, because their attack surface in this model is not a firewall or an endpoint. It is an OAuth consent dialog that an employee clicked six months ago.

The attack chain, decoded

Five stages, none of them novel on their own, all of them documented in the Vercel security bulletin, the Wiz analysis, and the SpecterOps writeup:

1. February 2026. A Context.ai employee searched for "Roblox auto-farm scripts" and downloaded an executable bundled with Lumma Stealer. The stealer harvested browser-stored credentials, session tokens, and OAuth grants. Hudson Rock's analysis identified this single infection as the patient zero of the entire campaign.
2. February-April 2026. The attackers held the credentials. No active intrusion. No alerts. Two months of dwell time. This is what stealer-as-a-service looks like at scale — credentials are stolen by one operator and sold or used downstream by another.
3. April 2026. One of the stolen OAuth tokens belonged to a Vercel engineer who had signed up for Context.ai's AI Office Suite using their corporate Google Workspace account. The OAuth scope was the standard productivity bundle: read and write Gmail, Docs, Drive, and Calendar.
4. April 19, 2026. Attackers used the OAuth token to authenticate as the Vercel engineer's Google Workspace account. No password. No MFA challenge. OAuth tokens are designed to be trusted. They pivoted into the engineer's Vercel internal account, enumerated environment variables across customer projects, and decrypted the ones Vercel had not flagged as sensitive.
5. April 23, 2026. Vercel disclosed publicly, published the malicious OAuth Client ID as an indicator of compromise, and began notifying affected customers. ShinyHunters dropped sample data and a $2 million ransom note.

The Context.ai Google Workspace OAuth Client ID Vercel published is 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Every Google Workspace administrator should search for that string in their environment today.

Why this is the SMB attack pattern

Enterprises have tools that catch this kind of OAuth lateral movement: cross-tenant identity protection, SaaS posture management platforms, anomaly detection on token replay. Most SMBs do not have any of that. They have a Google Workspace tenant, an Okta or Entra subscription, an MSP that resells Microsoft licenses, and a workforce that signs up for AI productivity tools faster than IT can inventory them.

The asymmetry is the problem. An attacker only needs one employee, one consumer-grade AI tool, and one "Allow All" click. The SMB defender needs visibility into every OAuth grant across the entire workforce, durable enough to detect a six-month-old grant that suddenly starts pulling Gmail metadata from a residential ASN in another country.

Building that visibility is the work. It is doable without enterprise tooling. The rest of this article is the four-step playbook for SMBs that runs entirely on what is already in your tenant.

The four-step SMB OAuth playbook

Step 1: Inventory every third-party OAuth grant this week

Every Google Workspace and Microsoft 365 tenant logs every OAuth grant. Most SMBs have never looked at the report. That changes this week.

In Google Workspace, navigate to Admin Console > Security > API Controls > Manage Third-Party App Access. The list you see is every external application your employees have authorized against their corporate Google account. Sort by date authorized, descending. Then sort by scope. Anything with broad scopes (Gmail, Drive, Calendar) and a vendor name you do not recognize is a row that needs an owner.

In Microsoft 365, the equivalent is Entra Admin Center > Enterprise Applications > All Applications, filtered for user-consented apps. Same exercise.

For the Vercel-specific check, search both consoles for the OAuth Client ID Vercel published. If you find a match, treat the affected user as compromised: revoke the grant, rotate the user's password and MFA factors, force a session reset, and audit the user's Gmail, Drive, and Calendar for unauthorized activity over the last 90 days.

Even if you find no match, the inventory exercise itself is the deliverable. The list you end up with is your shadow AI inventory. Most SMBs are shocked by what is on it.

Step 2: Lock down user-driven OAuth consent

The Vercel chain only worked because a single engineer was able to grant a third-party app "Allow All" Workspace permissions without an admin in the loop. That is the default in most tenants. It is not the right default for any tenant with sensitive data.

In Google Workspace, the relevant control is Admin Console > Security > API Controls > App Access Control. The recommended posture for an SMB:

• Restricted access to Gmail, Drive, and Calendar APIs. Third-party apps cannot read these unless an admin explicitly trusts them.
• Block any app marked "not yet reviewed by Google."
• Allow only apps on a written admin-approved list. The list lives in a shared doc that the IT and security leads update together.

The Microsoft 365 equivalent is Entra Admin Center > Enterprise Applications > Consent and Permissions. Set User consent for applications to "Do not allow user consent" or "Allow user consent for apps from verified publishers, for selected permissions." Then enable Admin consent requests so employees can request approval through a flow that lands in the IT inbox rather than just clicking past it.

This change will generate a handful of "I cannot connect this AI tool to my email" tickets in the first week. Treat that volume as a signal of how much shadow AI was already running, not as a reason to roll back.

Step 3: Alert on net new high-scope grants and on dormant tokens that wake up

The Vercel token sat unused for two months between the Context.ai breach and the Vercel intrusion. That is the highest-signal detection opportunity in the chain.

Two alerts cover most of the risk. Build them in whatever SIEM, Sumo, Wiz, or Workspace alerting tool you have. The logic is the same everywhere:

• New high-scope OAuth grants. Any user consenting to an app that requests https://www.googleapis.com/auth/gmail.readonly, gmail.modify, drive, or drive.readonly generates a ticket. Same for Microsoft 365 scopes like Mail.Read, Files.Read.All, full_access_as_user.
• Dormant token reactivation. Any OAuth token that has not been used in 30+ days suddenly being used to access Gmail or Drive generates a ticket. This is the alert that would have caught the Vercel chain.

A simple query approximation for Google Workspace audit logs, expressed against the Reports API:

# Pull OAuth token activity, the last 90 days
gcloud logging read \
  'protoPayload.serviceName="oauth2.googleapis.com" AND
   protoPayload.methodName="google.identity.oauth2.v1.Oauth2.TokenExchange"' \
  --freshness=90d --format=json > oauth_tokens.json

# Pivot in Python: token_id, last_used_before_30d, used_again_after
import json, datetime
tokens = json.load(open('oauth_tokens.json'))
# Group by token_id (client_id + user), find tokens with a gap of 30+ days
# Flag those where post-gap activity is to high-value scopes

The exact field names differ across tools. The detection idea is portable.

Step 4: Bound the blast radius of any one OAuth grant

Even with restricted consent and dormant-token alerting, an OAuth grant will eventually go bad. The question is how much of your environment that one bad grant can reach. Three controls compress the blast radius:

• Separate the OAuth surface from the privileged surface. Engineers, IT admins, finance admins, and HR admins should not be using their daily-use Workspace or Microsoft 365 account to log into SSO-protected production systems. A separate admin identity that has never been linked to any consumer SaaS tool is the modern equivalent of jump-host hygiene.
• Treat environment variables and secrets as sensitive by default. Vercel's specific failure was a binary "sensitive / non-sensitive" flag with the wrong default. Wherever you store secrets — Vercel, Netlify, GitHub Actions, GitLab CI, AWS Parameter Store, HashiCorp Vault — every secret should be sensitive unless someone made a deliberate decision otherwise. Audit the inverse: which secrets are currently non-sensitive, and why?
• Use phishing-resistant MFA on admin accounts. FIDO2 hardware keys on every privileged account in Google Workspace, Microsoft 365, Okta, GitHub, AWS, Vercel, Netlify, and your SSO. OAuth flows can still be abused after FIDO2, but the surface shrinks dramatically because privilege escalation paths get cut off.

The endpoint footnote

Lumma Stealer is sold as a $250-a-month subscription on Telegram. Its infection rate has tripled in the last twelve months. It is delivered through cracked software, game cheats, fake browser updates, and YouTube tutorial descriptions. There is no shortage of vectors. An SMB without managed EDR on every endpoint that touches corporate identity has an unbounded supply of patient-zero candidates.

The Vercel chain did not start with sophisticated nation-state tradecraft. It started with one developer searching for game scripts on a corporate laptop. The remediation pattern that ends this kind of incident on day one rather than day sixty is unglamorous: EDR with active blocking on every workforce endpoint, BYOD policy that excludes corporate identity from unmanaged devices, and quarterly user education that explains why downloading game scripts on the work laptop is now a supply chain incident waiting to happen.

What "ready" looks like

You will not stop every Lumma Stealer. You will not catch every malicious OAuth app on the day it goes live. The goal is not perfection. The goal is making sure that on the day a vendor like Context.ai publishes an incident bulletin, you can answer four questions inside an hour: Did any of our users authorize that app? With what scopes? When was the token last used? Has it touched our data since the disclosure window opened? If you can answer those four questions today, you are ahead of where Vercel's affected customers were on April 19.