Identity is the New Lateral Movement: Deconstructing the Vercel OAuth Supply Chain Breach

On April 19, 2026, Vercel disclosed a security breach that allowed unauthorized access to internal environments and a specific subset of customer credentials.

The scary part? The attack didn’t target a vulnerability in Vercel’s code, its build system, or its runtime infrastructure. Instead, it moved entirely through identity providers, leveraging a classic modern supply chain escalation: compromising a minor third-party SaaS vendor to silently walk right past the perimeter of a major enterprise.

1. The Anatomy of the Failure

The Initial Compromise: Lumma Stealer & Context.ai

The attack chain began in February 2026, when a core employee at the AI startup Context.ai accidentally downloaded a malicious Roblox “auto-farm” exploit script. The script deployed Lumma Stealer, harvesting corporate credentials, including the company’s support@context.ai account and access keys for Google Workspace, Supabase, Datadog, and Authkit.

By March 2026, the threat actors used these credentials to execute a broader breach of Context.ai’s AWS infrastructure. While Context.ai blocked the AWS intrusion, a critical blindspot remained: the attackers quietly exfiltrated valid OAuth tokens held on behalf of Context.ai’s consumer users.

The Lateral Pivot: The “Allow All” Trap

A Vercel employee had previously signed up for Context.ai’s consumer AI Office Suite using their enterprise Google Workspace account. During signup, they granted the app broad “Allow All” permissions.

When the threat actor replayed the stolen OAuth token, Google’s APIs treated the request as entirely legitimate. No password was required, and no multi-factor authentication (MFA) was triggered because the app was already pre-authorized.

Because Vercel’s internal enterprise OAuth configurations permitted broad scoping, the attacker assumed the employee’s identity, bypassed perimeter security controls, and pivoted straight into Vercel’s internal environments.

Zero Trust is the way because of such 3rd party incidents

The Data Harvest

Once inside Vercel’s systems, the attacker enumerated and read project environment variables.

Vercel encrypts all environment variables at rest. However, they offer a distinct architectural split: variables could be designated as regular or “sensitive”. The attacker successfully extracted secrets from variables not marked as sensitive, compromising a limited subset of customer credentials.

2. Blast Radius Assessment

Extracted / ExposedSafely Protected / UnaffectedEnvironment variables not marked as sensitiveEnvironment variables explicitly marked as “sensitive”Vercel Deployment Protection tokens for the affected subsetCore build and edge runtime infrastructureUnauthorized access to localized internal tooling and Slack/Linear environmentsVercel’s open-source supply chain (Next.js, Turbopack)

Note on Threat Actor Claims: A threat actor using the “ShinyHunters” persona claimed responsibility, attempting to sell an alleged Vercel database containing NPM and GitHub publish tokens for $2 million. Google Threat Intelligence Group (GTIG) and security researchers later assessed this actor to be an imposter inflating their notoriety. Vercel collaborated with Microsoft, GitHub, npm, and Socket, finding zero evidence of package or source control compromise.

3. The Prevention Playbook

For Infrastructure Vendors (Hardening Identity)

• Default to Zero Trust for Secrets: Do not make secret masking optional. Vercel responded to this incident by updating their dashboard to default all new environment variable creations to “sensitive”.
• Strict Enterprise OAuth Controls: Restrict employee-level OAuth applications within Google Workspace or Microsoft 365. Block high-value scopes (Drive, Gmail, Calendar) by default, forcing third-party integrations onto an explicit administrative allow-list.
• Monitor Token Anomalies: Implement behavioral alerting on Google Workspace OAuth logs. Flag tokens that suddenly activate after 30+ days of dormancy, or those making rapid API calls from unexpected geographical locations.

For Engineering Teams (Architecting for Resilience)

• Audit Active OAuth Grants: Regularly export your organization’s third-party app access logs. Review every active OAuth client ID (such as the compromised Context.ai IDs 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com and 110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com) and instantly revoke unrecognized services.
• Treat Every Secret as Runtime-Only: Never store production API keys, database strings, or certificates in plaintext configuration variables. If you are using Vercel, ensure the Sensitive checkbox is checked so the values are never readable by humans, dashboards, or CLIs after creation.
• Enforce Deployment Protection: Ensure your Vercel Deployment Protection is set to Standard at a minimum to prevent unauthorized access to preview and staging URLs via leaked tokens.

The Takeaway

Traditional Supply Chain Attack:
[Malicious Dependency] ──> [Infiltrates Codebase] ──> [Compromises Production]

Identity-Based Supply Chain Attack:
[Compromised Minor SaaS App] ──> [Stolen OAuth Token] ──> [Bypasses Corporate Perimeter]

This incident underscores a shifting paradigm in modern cloud security: OAuth is the new lateral movement.

When a developer clicks “Login with Google” on an unvetted AI productivity tool, they are potentially creating a persistent, passwordless bridge straight into corporate infrastructure. Security posture is no longer defined solely by the security of your own code, but by the youngest, least mature SaaS vendor your team has authorized. Until OAuth tokens are treated with the exact same cryptographic severity as root credentials, the industry will continue to re-read this exact breach blueprint with different vendor names attached.

As we continue this Case to Case Study series, I’m looking for fresh perspectives. If you know of a case study that handled these problems differently — or perhaps a “better alternative” solution that I haven’t covered — I’d love to feature it.

Drop me a mail at kar.kartik19@gmail.com with your ideas or requests for what I should cover next. Let’s keep deconstructing these systems together.