OAuth Supply Chains as the New Lateral Movement
In April 2026, Vercel disclosed a breach that traced through a third-party AI tool called Context AI. The attacker did not exploit a vulnerability in Vercel's infrastructure. Instead, they compromised a Context AI employee's workstation, stole OAuth tokens that a Vercel employee had previously authorized, and used those tokens to move laterally into Vercel's internal systems. The breach bypassed MFA, survived password rotation, and required no zero-day exploit. Dark Reading called it: "Stolen OAuth tokens are the new attack surface, the new lateral movement." The pattern is not specific to Vercel. It is replicable across any platform that chains third-party OAuth integrations — which is most of them.
The Attack: How OAuth Tokens Became a Kill Chain
The breach unfolded in five stages. Each stage moved through a different trust boundary without triggering the defenses of the next.
Stage 1: Initial Access via Infostealer
A Context AI employee downloaded what appeared to be a Roblox cheat tool. It was Lumma Stealer, a commodity infostealer that harvested the employee's Google Workspace and AWS credentials from their browser. This is the most common initial access vector in enterprise breaches — credential theft from an endpoint that security teams cannot directly control.
Stage 2: Third-Party Environment Compromise
Using the harvested credentials, the attacker accessed Context AI's AWS environment. From there, they exfiltrated OAuth tokens that Context AI's application held for users who had granted permissions. These tokens represented authenticated sessions for every user who had ever clicked "Allow" on Context AI's OAuth consent screen.
Stage 3: OAuth Token Hijack
At least one Vercel employee had previously authorized Context AI's "AI Office Suite" with "Allow All" permissions on their Google Workspace account. This granted Context AI's application a refresh token with broad scope — access to email, calendar, drive, and workspace metadata. The attacker used this stolen token to hijack the Vercel employee's Google Workspace session. The token was valid. The session was authenticated. MFA had already been satisfied when the user originally consented.
Stage 4: Lateral Movement into Vercel
From the compromised Google Workspace account, the attacker moved into Vercel's internal systems. Environment variables not marked as "sensitive" were stored unencrypted and could be enumerated. At least one credential — an OpenAI API key — was detected in the wild on April 10, nine days before Vercel's April 19 disclosure.
Stage 5: Data Exfiltration and Sale
The attacker listed stolen data on BreachForums for $2 million. The listing claimed approximately 580 employee records, source code, API keys and tokens, GitHub and NPM credentials, internal communications, and access to a Linear workspace. A group branding itself as ShinyHunters claimed responsibility, though the organization publicly denied involvement.
The Pattern: OAuth Supply Chain Attacks at Scale
The Vercel breach is one instance of a broader pattern. Three distinct OAuth attack vectors are now in active exploitation:
Vector 1: Third-party application compromise. An attacker compromises a legitimate OAuth application and uses its stored tokens to access user accounts. This is the Vercel vector. The application (Context AI) was not malicious. It was a real product with real users. The trust it held was legitimate. The compromise was in the application's infrastructure, not in the OAuth protocol itself — but the protocol provided no mechanism to detect or revoke the stolen grants until manual intervention occurred.
Vector 2: Device code phishing. Microsoft documented a campaign in April 2026 that used the OAuth device code flow (RFC 8628) to bypass MFA. The attacker generates a device code at a legitimate login page and sends it to the victim — often embedded in what appears to be a Teams meeting link or a shared document. The victim enters the code at the real Microsoft login page, authenticates with MFA, and unknowingly authorizes the attacker's session. The attacker receives a refresh token that persists indefinitely, bypasses conditional access policies, and survives password changes. Barracuda reported 7 million device code phishing attacks in four weeks. Push Security measured a 37.5x increase in 2026.
Vector 3: Overpermissioned OAuth grants. Users routinely grant "Allow All" permissions to third-party applications without reviewing the scope. These grants persist across password rotations and MFA challenges. They are rarely audited after initial consent. A single overpermissioned grant to a compromised application creates a persistent, authenticated backdoor into the user's workspace — invisible to the user and to most SIEM configurations.
| Attack Vector | Bypasses MFA | Survives Password Rotation | Detection Difficulty | Active Campaigns (2026) |
|---|---|---|---|---|
| Third-party app compromise | Yes | Yes (refresh tokens) | High — token usage appears legitimate | Vercel, Salesloft, Drift |
| Device code phishing | Yes | Yes (refresh tokens) | High — user-initiated consent | Microsoft 365 (340+ orgs), Salesforce (1,000+ orgs) |
| Overpermissioned grants | N/A (post-MFA) | Yes (refresh tokens) | High — no anomalous access pattern | Pervasive (user behavior, not campaign) |
Exceptions: When OAuth Supply Chain Risk Is Lower
Not every organization faces the same level of exposure. The risk concentrates in specific architectural patterns:
- Organizations with fewer than 10 third-party OAuth integrations have a manageable attack surface. Each integration can be manually audited, scoped, and monitored without automation. The cost of a breach is bounded by the small number of trust edges.
- Environments with conditional access and continuous access evaluation (CAEP/SSF) can revoke sessions in near-real-time when risk signals change. OAuth tokens bound to these evaluations have a shorter effective lifetime, even if the refresh token itself persists.
- Organizations that enforce token binding (DPoP or mTLS) make stolen tokens useless outside the original client. The attacker cannot replay a token from a different infrastructure because the token is cryptographically bound to the originating client's key pair or certificate.
- Single-tenant, self-hosted environments that do not allow third-party OAuth grants eliminate the attack surface entirely. This applies to air-gapped infrastructure and organizations that have formally banned third-party workspace integrations.
The threshold where risk becomes critical: when an organization has more third-party OAuth grants than its security team can audit quarterly. For most mid-size companies, this threshold is crossed at approximately 25 to 40 active integrations. Above that number, manual review breaks down and automated governance becomes necessary.
The Honest Assessment
OAuth supply chain attacks exploit a fundamental design assumption: that the party holding the token is the same party that was granted the token. The OAuth protocol does not verify who is using a bearer token. It verifies that the token is valid. As Contrast Security CISO David Lindner summarized after the Vercel breach: "No exploit. No zero-day. Just an unsanctioned AI tool, an overpermissioned OAuth grant, and a gaming cheat download."
The defensive landscape breaks down as follows:
| Defense | What It Stops | What It Does Not Stop | Implementation Status (2026) |
|---|---|---|---|
| MFA enforcement | Direct credential theft | Post-MFA token theft, device code phishing | Widely deployed |
| Password rotation | Password reuse, credential stuffing | Refresh token persistence | Widely deployed |
| Conditional access (IP/device) | Access from unknown locations | Token replay from app infrastructure (appears legitimate) | Moderate adoption |
| OAuth app allowlisting | Known-malicious applications | Legitimate applications with compromised infrastructure | Low adoption |
| DPoP token binding (RFC 9449) | Token replay from different client | Compromise of the client's private key itself | Emerging — major IdPs adding support |
| CAEP/SSF continuous evaluation | Persistent sessions after risk change | Attacks that do not trigger risk signals | Early — OpenID Foundation spec published Feb 2026 |
| Identity attack path mapping | Unmodeled trust edges (pre-breach) | Trust edges that are modeled but inadequately secured | Nascent — SpecterOps framework, limited tooling |
SpecterOps' analysis of the Vercel breach introduced a concept worth understanding: the Clean Source Principle. The moment the Vercel employee clicked "Allow All" on Context AI's consent screen, Context AI's infrastructure became a Clean Source dependency for Vercel's identity environment. That dependency was never modeled in any identity architecture diagram. It was never risk-assessed. It was never monitored. It was created outside IT's visibility by an employee adopting a shadow AI tool — exactly the pattern that accelerates as AI coding assistants and agentic tools proliferate.
The uncomfortable truth: most organizations have a map of their identity dependencies that is incomplete by design. OAuth grants create trust edges that are invisible to the identity architecture. Users add them without visibility. Security teams cannot audit what they cannot see. The gap between the real trust graph and the documented trust graph is the attack surface.
Actionable Takeaways
- Inventory all third-party OAuth grants immediately. Export the list of applications that hold refresh tokens for your workspace. Google Workspace, Microsoft Entra, and GitHub all provide admin APIs for this. Count the grants. If the number exceeds what your security team can audit quarterly, you have a governance gap.
- Revoke grants for applications no longer in active use. Dormant tokens are latent access paths. If an employee authorized an AI tool six months ago and has not used it since, that token still provides authenticated access to the employee's workspace.
- Enforce admin approval for new OAuth grants. Both Google Workspace and Microsoft Entra support policies that require administrator approval before third-party applications receive tokens. Enable this policy for all scopes above basic profile access.
- Implement DPoP token binding where your identity provider supports it. RFC 9449 binds tokens to a cryptographic key pair held by the client. If the token is stolen and replayed from a different client, the verification fails. Major identity providers are adding DPoP support through 2026. Prioritize applications with the broadest scope grants for DPoP enrollment.
- Map your identity attack paths. SpecterOps' Clean Source Principle provides a framework: for every OAuth grant in your environment, trace the trust edge back to the application's infrastructure. If that infrastructure were compromised, what workspace data could the attacker access? This mapping exercise surfaces the blast radius of each third-party integration.
- Classify environment variables as sensitive by default. The Vercel breach extracted credentials from environment variables not marked as sensitive. Default to encrypted storage for all environment variables. Require explicit opt-out (with justification) rather than opt-in for encryption.
- Monitor for device code flow abuse. If your organization uses Microsoft 365, enable logging for device code flow authentication events. The April 2026 campaign used this flow exclusively. Detection logic: flag any device code sign-in from an unusual location or where the user's IP does not match the device code request IP.
OAuth was designed to solve the problem of sharing access without sharing passwords. It achieved that goal. It also created a secondary problem that most organizations have not yet recognized: every OAuth grant extends the trust boundary of the identity environment to include the infrastructure of a third-party application the user may have authorized once and forgotten. The Vercel breach is not an anomaly. It is the first high-profile instance of a pattern that will repeat as long as trust edges remain unmodeled and ungoverned. The defense is not to abandon OAuth — it is to see the full graph, bind the tokens, and shrink the blast radius before the next application is compromised.