One OAuth Token. 700 Enterprise Customers. The Vercel Supply Chain Attack Explained.

OAuth Supply ChainVercel third-party OAuth integration — enterprise
700+
Orgs Affected
1
OAuth Token Exploited
3
Major Infosec Firms Hit
Apr 19
Disclosure Date

On April 19, 2026, Vercel disclosed a supply chain compromise that reached over 700 enterprise customers. The attack did not break any Vercel systems directly. There were no CVEs, no unpatched vulnerabilities, no brute-forced passwords. The entry point was a single OAuth token, harvested from a developer's machine at a third-party AI integration vendor called Context.ai. That token was valid. The attacker used it like a key because it was one.

Among the affected organizations: Cloudflare, Palo Alto Networks, and Zscaler. Three of the largest names in enterprise security, reached not by targeting their own perimeters, but by targeting a smaller vendor none of them directly managed.

How the Token Was Stolen

Lumma Stealer is an infostealer-as-a-service tool available on criminal forums for roughly $250/month. It targets browser credential stores, session cookies, and application tokens stored on disk or in memory. A Context.ai developer's machine was infected with Lumma Stealer. The malware harvested an OAuth token that the developer's browser or local tooling had cached for their Vercel integration.

OAuth tokens for platform integrations are typically long-lived. They do not expire after a session ends. They sit in browser storage, in ~/.config directories, in application keystores. Lumma Stealer knows exactly where to look. Once exfiltrated, the token gave the attacker the same access the developer had: a live, authenticated connection to Vercel's internal infrastructure through the Context.ai integration.

Key Finding

OAuth tokens stolen via infostealer malware are indistinguishable from legitimate sessions. There are no failed login attempts, no anomalous authentication events from unknown IPs. The token is valid. The session looks clean.

The Lateral Movement Path

Modern SaaS platforms maintain an OAuth trust graph. When you install a third-party integration, you grant it scopes: read access here, write access there. Context.ai had a Vercel integration that, by design, had access to Vercel's internal APIs. The attacker did not need to compromise Vercel directly. They compromised Context.ai's OAuth grant, which gave them a doorway into Vercel's systems, which gave them visibility into Vercel's customer list and associated data.

Attack Path
1
Developer Machine Infected
Lumma Stealer deployed on a Context.ai developer's endpoint via phishing or trojanized software
2
OAuth Token Harvested
Stealer exfiltrates cached OAuth token for the Context.ai to Vercel integration from local credential store
3
Vercel Internal Access
Attacker authenticates to Vercel's internal APIs using the valid token; no anomaly triggered
4
Customer Data Accessed
700+ enterprise customer records, configurations, and associated data reached via Vercel's infrastructure
5
Discovery and Disclosure
Vercel detects unauthorized access, revokes tokens, notifies affected customers; April 19 public disclosure

Why This Threat Model Is Invisible to Most Teams

Most enterprise security teams model their perimeter around direct access: who can log into our systems, what credentials exist, which endpoints are exposed. The OAuth trust graph sits outside this model. Third-party integrations are provisioned by developers and product teams, often without security review. The integration vendor's security posture is rarely assessed. The scopes granted are rarely audited after the fact.

A vendor your security team has never heard of may have a live OAuth connection to your production Vercel, GitHub, Salesforce, or Slack environment right now. That connection is authenticated with a long-lived token. If that vendor's developer gets hit with an infostealer, the token goes with it.

Audit Recommendation

Run an OAuth integration audit on every platform your org uses. Vercel, GitHub, Slack, Salesforce, Google Workspace. For each integration: who installed it, what scopes it holds, when it was last used, and whether the vendor has been assessed. Revoke anything that cannot be justified.

What Defenders Should Do

The technical controls here are not novel, but they are underimplemented. First: enumerate your OAuth integrations. Most platforms expose this in admin settings. Build a list. Second: scope creep is real. Many integrations hold broader permissions than they need. Review scopes and reduce them. Third: set token expiration policies where the platform supports it. Short-lived tokens blunt the impact of theft. Fourth: treat your vendor list as part of your attack surface. Third-party risk management should include OAuth integration vendors, not just vendors with SOC 2 reports on file.

The Vercel breach is a clean example of a threat that will repeat. The OAuth trust graph is large, poorly mapped, and actively targeted. The organizations that enumerate it now are the ones that avoid being in the next disclosure.

Not Sure What's in Your OAuth Trust Graph?

RedEye Security conducts third-party integration assessments and supply chain risk reviews for critical infrastructure operators and enterprise teams.

Request an Assessment