How a game script on a vendor's laptop gave attackers the keys to a $9 billion platform's customer secrets

The Context

Vercel is the platform that hosts and deploys web applications for millions of developers. It is best known as the company behind Next.js, a framework with roughly 6 million weekly downloads. Vercel is valued at approximately $9.3 billion and serves customers including major Web3 projects, fintech companies, and enterprise software teams. When developers deploy on Vercel, they store secrets in "environment variables": API keys, database passwords, and deployment tokens their applications need to run.

Context.ai was a small startup offering an "AI Office Suite" that let users connect AI agents to external applications via OAuth. OAuth (Open Authorization) is the standard that lets you click "Sign in with Google" or "Connect your calendar" without giving a third-party app your password. Instead, the app receives a token—a short string proving you authorized it—which it can use to act on your behalf. Context.ai stored those tokens so its AI agents could take actions in connected applications.

The Attack, Phase by Phase

Phase 1: Infostealer Infection at the Vendor

In February 2026, a Context.ai employee downloaded Roblox "auto-farm" exploit scripts onto a corporate laptop. These scripts are a well-documented delivery vehicle for Lumma Stealer, a malware-as-a-service tool sold on criminal forums. Once installed, Lumma Stealer harvested everything stored in the browser: Google Workspace credentials, session cookies, OAuth tokens, and logins for Supabase, Datadog, and Authkit.

The infected employee was a core member of the context-inc Vercel team, and their browser history showed direct prior access to Vercel's administrative endpoints, including environment variable settings and production logs for the valinor project. The attacker now had a map of exactly where to go next.

Phase 2: AWS Intrusion and the Investigation That Missed the Key

In March 2026, the attacker used the harvested credentials to breach Context.ai's AWS environment. Context.ai detected the intrusion, contained it, and hired CrowdStrike to investigate. The investigation confirmed the AWS breach—but did not identify that the attacker had also exfiltrated the OAuth tokens Context.ai held for its AI Office Suite users, including a token belonging to a Vercel employee who had granted "Allow All" permissions when connecting their corporate Google account.

The investigation closed. The stolen token remained valid. The downstream exposure at Vercel went undetected for approximately one month.

Phase 3: OAuth Pivot into Vercel

With the stolen token, the attacker impersonated the Vercel employee's Google Workspace identity without needing their password or MFA. OAuth tokens bypass both. Vercel's internal Google Workspace configuration had permitted the "Allow All" permission grant to propagate into the enterprise tenant, giving the attacker broad access to the employee's corporate account and, through it, Vercel's internal systems and dashboards.

Phase 4: Platform-Scale Enumeration and Extortion

From the compromised account, the attacker enumerated customer project environment variables that had not been marked as "sensitive." Vercel stores sensitive-flagged variables in encrypted format, unreadable from dashboards. Non-sensitive variables were accessible. The attacker read API keys, deployment credentials, and other secrets across a subset of customer projects.

As proof of access, the attacker exfiltrated 580 Vercel employee records and screenshots of Vercel's internal Linear instance, then posted the data on BreachForums under the ShinyHunters persona, demanding million. At least one customer's OpenAI API key had already been used in the wild by April 10—nine days before Vercel's public disclosure on April 19.

What Made This Possible

1. Unaudited OAuth trust relationships. A single employee's consumer app authorization created a standing credential inside Vercel's enterprise environment. No one at Vercel had visibility into the fact that a third-party token store, controlled by a startup with no enterprise security controls, held a key to their internal systems.

2. Incomplete incident response scope. When Context.ai hired CrowdStrike, the investigation confirmed what was directly visible: the AWS intrusion. It did not scope what data the attacker had exfiltrated from the token store, or what downstream systems those tokens could reach. A breach investigation at one organization left a loaded weapon pointed at a completely different organization.

3. Permissive enterprise OAuth consent policies. Vercel's Google Workspace configuration allowed a consumer "Allow All" grant to propagate into the enterprise tenant. This is a configuration choice, not a platform limitation. Google Workspace administrators can restrict which third-party applications are permitted to request broad permissions from enterprise accounts. That restriction was not in place.

The systemic lesson: the enterprise security perimeter has silently expanded to include every OAuth authorization any employee has ever clicked. Most organizations have no inventory of that graph.

What Should Have Stopped This

Every defense that would have reduced the blast radius here shares one trait: it does not depend on the compromised vendor's own security posture.

• OAuth application allowlisting. Google Workspace and Microsoft Entra both allow administrators to restrict which third-party applications can request OAuth access from enterprise accounts. An allowlist would have prevented the Context.ai consumer app from receiving a token scoped to the Vercel enterprise tenant in the first place.
• Token lifetime limits and rotation. OAuth tokens that expire quickly and require re-authorization limit the window an attacker has to replay a stolen token. Long-lived or non-expiring tokens remain valid indefinitely after theft.
• Sensitive variable classification. Vercel's platform distinguishes between sensitive and non-sensitive environment variables. Customers who had marked their credentials as sensitive were not exposed. This is a customer-side configuration choice most users had not made.
• Third-party SaaS access audits. A periodic review of OAuth applications authorized by enterprise accounts—available in Google Workspace and Microsoft Entra admin consoles—would surface applications like the Context.ai AI Office Suite before they become an attack vector.

The Takeaway

This attack did not exploit a vulnerability in Vercel's code. It exploited the fact that a legitimate authorization, issued by one employee to one consumer app, persisted as a replayable credential in a token store that Vercel had no visibility into and no control over. The attacker never needed to touch Vercel's infrastructure directly. They walked in through a door a Vercel employee had opened months earlier at a completely different company.

This is the same class of failure as the Stryker Intune wipe: a trusted layer weaponized against the organization it was built to serve. In the Stryker case, the weapon was an administrative tool. Here, the weapon is an identity token. The meta-pattern is identical: systems fail when they trust a boundary the attacker already controls.

Pattern to remember: A compromised vendor's token store is a master key ring for every enterprise account that vendor's users ever connected.

What changed: Breach investigations must now treat token store exfiltration as a mandatory scope item, because a stolen bearer credential reaches downstream organizations that were never party to the original incident.

The Technical Mechanism

The attack chain is a four-stage supply chain pivot: infostealer infection at a vendor, OAuth token exfiltration from the vendor's token store, token replay against an enterprise identity provider, and platform-scale secret enumeration.

Stage 1: Lumma Stealer delivery via game exploit scripts. Lumma Stealer is a malware-as-a-service infostealer available on criminal forums. It targets browser credential stores, session cookies, and autofill data. The delivery vector here was Roblox "auto-farm" executor scripts, a well-documented Lumma distribution channel. The malware harvested the full browser credential set from the infected Context.ai employee's machine, including Google Workspace session tokens, the support@context.ai account credentials, and OAuth tokens stored in browser autofill fields. Hudson Rock's analysis of the infection log confirmed browser history showing direct prior access to vercel.com/context-inc/valinor/settings/environment-variables, /settings, and /logs.

Stage 2: AWS intrusion and token store exfiltration. The attacker used the harvested credentials to authenticate to Context.ai's AWS environment. During this intrusion, they accessed the token store backing Context.ai's AI Office Suite product. This store held OAuth tokens issued by consumer users who had connected external applications to the AI Office Suite. The relevant token was issued by a Vercel employee who had authorized the app with broad ("Allow All") permissions against their Vercel enterprise Google Workspace account. The CrowdStrike investigation of the AWS breach did not identify the token store exfiltration as a finding, leaving the downstream exposure undetected.

Stage 3: OAuth token replay against Google Workspace. The attacker replayed the stolen OAuth token against Google's authorization servers. Because OAuth tokens are bearer credentials (possession equals authorization), no password or MFA challenge was triggered. Vercel's Google Workspace OAuth consent policy had not restricted third-party application permission scopes, allowing the consumer "Allow All" grant to propagate into the enterprise tenant. The attacker obtained a valid Google Workspace session for the Vercel employee's account.

Stage 4: Environment variable enumeration. From the compromised Google Workspace session, the attacker accessed Vercel's internal dashboards. Vercel's platform distinguishes between sensitive environment variables (encrypted at rest, not readable from dashboard views) and non-sensitive variables (accessible from internal views). The attacker enumerated non-sensitive variables across a limited subset of customer projects, reading API keys, deployment credentials, and other secrets. The IOC published by Vercel is the OAuth App client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Nudge Security CTO Jaime Blasco independently corroborated this IOC by tracing it to a now-removed Context.ai Chrome extension listing.

CVE and Advisories

No CVE applies to this incident. The attack did not exploit a software vulnerability. It exploited a combination of a commodity infostealer infection, an incomplete incident response investigation, and permissive OAuth consent configuration. The relevant advisory is Vercel's official security bulletin: Vercel April 2026 Security Incident.

Google Workspace administrators should check for the IOC OAuth App client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com in their tenant's authorized application list.

MITRE ATT&CK Mapping

Indicators of Compromise

The single confirmed IOC published by Vercel is the Context.ai OAuth App client ID:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Google Workspace administrators should audit their tenant's third-party OAuth application authorizations for this client ID and revoke any active tokens associated with it. Vercel's bulletin advises immediate revocation.

Network-level and endpoint IOCs for the Lumma Stealer infection at Context.ai have not been published as of April 20, 2026. The infection predates the breach by approximately two months, limiting the forensic utility of endpoint IOCs for Vercel's downstream customers.

Detection difficulty is high for the downstream pivot stage: the attacker used a valid OAuth token to authenticate, generating log entries indistinguishable from legitimate user activity unless the token's origin (the Context.ai OAuth app client ID) is specifically flagged.

Attribution

Attribution is unresolved. A threat actor using the ShinyHunters persona posted the alleged Vercel data on BreachForums on the night of April 19, 2026, demanding $2 million. Threat actors linked to recent attacks attributed to the actual ShinyHunters extortion gang told BleepingComputer on April 20 that they are not involved in this incident. Vercel has not attributed the attack to any specific group or nation-state. Vercel CEO Guillermo Rauch stated he "strongly suspects" the attacker's operational velocity was "significantly accelerated by AI," but this is an assessment of tradecraft, not an attribution claim. Google Mandiant is engaged in the ongoing investigation; no attribution findings have been published as of April 20, 2026.

Primary Sources