The Vercel Breach 2026: How a Roblox Exploit Cheat Script Triggered a $2M Supply Chain Attack on the Web's Front Door

One Employee. One Cheat Script. Millions at Risk.

Somewhere in February 2026, an employee at Context.ai (a small AI productivity startup) downloaded what they believed was a Roblox auto farm script. It turned out to be a Lumma Stealer payload. Within seconds, the malware harvested their Google Workspace credentials, their Supabase keys, their Datadog access, and the support@context.ai account login.

That support account was the skeleton key.

Two months later, on April 19, 2026, Vercel (the cloud deployment platform underpinning a massive slice of the modern web, home to Next.js, serverless infrastructure, and the CI/CD pipelines of hundreds of thousands of developers) published a security bulletin confirming a breach of its internal systems. Customer environment variables were compromised. A threat actor claiming the ShinyHunters persona posted a BreachForums listing offering the stolen Vercel data for sale at $2 million, calling it the setup for "the largest supply chain attack ever."

The Vercel breach was not a zero-day exploit or a nation-state intrusion. It was a Roblox cheat script, a forgotten OAuth permission, and a cloud deployment platform with non-sensitive environment variables stored in plaintext.

Vercel

What is the Vercel Breach?

Vercel is one of the most important infrastructure companies in modern web development. It's the creator and primary maintainer of Next.js (the React framework used by major enterprises worldwide) and operates a cloud hosting and deployment platform used by developers to build, preview, and deploy web applications. Vercel stores customer environment variables: the passwords, API keys, database credentials, and service tokens that make applications function. When a developer deploys an app on Vercel, those secrets live in Vercel's infrastructure.

The Vercel breach is a textbook OAuth supply chain attack.

It worked like this:

Imagine an employee at your office uses a third party browser extension and, during setup, clicks "Allow All" when the extension asks for permissions to their corporate Google account. That extension's company gets hacked. The attacker uses the stolen connection to walk into the employee's Google account and from there, into your company's internal systems.

The attacker had already been inside Context.ai's AWS environment for a month before Vercel even knew what was happening.

This was a multi-stage, cross-organization supply chain attack.

1. Infostealer Infection (February 2026)

   1. Context.ai employee downloads Roblox "auto-farm" exploit script

   2. File contains Lumma Stealer payload

   3. Stealer harvests from infected machine:

      1. Google Workspace credentials (context.ai account)

      2. support@context.ai account credentials

      3. Supabase access keys

      4. Datadog login credentials

      5. Authkit tokens

2. Context AI AWS Breach (March 2026)

   1. Attacker uses harvested credentials to access Context.ai AWS environment

   2. Context AI identifies and blocks unauthorized access

   3. Context AI notifies "one customer" and believes incident is contained

   4. Attacker has already exfiltrated OAuth tokens for Context.ai users

   5. Tokens include one belonging to a Vercel employee who had signed up for Context.ai's AI Office Suite with their Vercel enterprise Google account and granted "Allow All" permissions

3. Vercel Google Workspace Takeover (April 2026)

   1. Attacker uses stolen OAuth token to access the Vercel employee's Google Workspace account

   2. Vercel's enterprise OAuth configuration allowed the "Allow All" permission to propagate across the enterprise tenant

   3. Attacker gains access to Vercel internal environments

4. Environment Variable Extraction

   1. Environment variables NOT marked as "sensitive" are readable in plaintext. These include API keys, tokens, and service credentials stored by customers in non-sensitive env var fields

   2. Sensitive variables (encrypted at rest) were NOT accessed (no evidence of access confirmed by Vercel)

5. Data Listing and Extortion (April 19, 2026)

   1. Threat actor posts on BreachForums claiming to be ShinyHunters, offers Vercel databases, access keys, employee accounts, source code for sale: asking price $2 million

   2. Vercel publishes security bulletin same day

   3. Real ShinyHunters denies involvement via BleepingComputer

   4. BreachForums post subsequently deleted

   5. No ransom payment confirmed; no demand formally communicated to Vercel

Why "Allow All" OAuth Is So Dangerous

But what is Oauth exactly?

Commonly seen as "Login with Google/Facebook" feature, it uses access tokens to provide limited, temporary permissions to an applications rather than giving them full credentials.

1. Someone walks up to your website and asks to come in. You have no idea who they are and have very little idea how to check. You ask Facebook or Google (or whoever) to check for you since they have a whole system in place to do that.

2. They tell Facebook/Google who they are (usually through a reroute to a login page or through a pop up and they supply their Facebook credentials) and then Facebook turns around and tells you, 'Yeah, they're who they say they are' and hand you a signed piece of paper with their seal of approval on it (Rerouted back to your application with an auth code).

3. Now that Facebook said it was okay and gave you the thumbs up, you can now tell Facebook that you're cool with letting them in if they're cool with it. Facebook says 'okay', tells the person what information Facebook is going to tell you, and then gives them a temporary key (passing the auth code for a web token).

The critical architectural failure here was not at Vercel, not at Context.ai, but at the intersection of how Google Workspace OAuth and enterprise identity management interact.

When a user in an enterprise Google Workspace tenant installs a third-party OAuth application and grants broad permissions such as <Allow All> or <Read All>, those permissions can propagate at the enterprise tenant level depending on how the Workspace is configured. A single employee's permission grant doesn't just affect their account, it can expose shared drives, internal documents, and enterprise identity data across the organization.

The attacker didn't need to compromise Vercel directly. They needed one employee to have done something completely normal, connect a productivity tool to their work Google account, at a company that itself had weak endpoint security.

Vercel published the following IOC immediately upon confirming the breach:

Malicious OAuth App Client ID:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

SOC Incident Response Workflow

• Immediate audit: Check for the malicious OAuth Client ID in your Google Workspace Admin Console and revoke any authorizations immediately.

• Rotate all non-sensitive Vercel environment variables that existed before April 19, 2026. Even if not confirmed exfiltrated, the exposure window spans weeks. Treat all non-sensitive env vars from the pre-disclosure period as compromised.

• Scan cloud environments for credential usage from unexpected IP addresses or user agents. Review AWS CloudTrail, GCP Audit Logs, and Azure Activity Logs for any API calls using Vercel-stored credentials from IPs outside your known developer ranges between March and April 2026.

• Check endpoints of users who connected to Context.ai. If any user in your organization granted the Context.ai OAuth app access to their Google account, check their endpoint for Lumma Stealer artifacts. The infection propagation path may extend beyond Vercel.

Prevention & Best Practices

• Implement OAuth app allow-listing in Google Workspace to explicitly allow only pre-approved OAuth apps and block all others.

• Never grant "Allow All" OAuth permissions to third-party tools.

• Mark ALL environment variables containing secrets as sensitive.

• Enforce endpoint security and endpoint detection on all corporate devices. 

The Vercel breach will be studied not because of its technical sophistication (there are no CVEs, no zero-days, no memory exploits in this kill chain) but because of what it reveals about the architecture of modern software development: a dense web of OAuth connections, third-party tools, shared identity providers, and deployment platforms where any link in the chain can become the entry point for the entire chain.

The Roblox script that started this chain cost nothing to download. The breach it enabled is being offered for $2 million. That asymmetry between the trivial cost of initial access and the catastrophic downstream value of a platform credential store is the defining security equation of the modern web.

Until OAuth authorization is treated as a security-critical decision rather than a routine click-through, this story will keep getting retold with different company names.

Happy cyber-exploration! 🚀🔒

Note: Feel free to drop your thoughts in the comments below - whether it's feedback, a topic you'd love to see covered, or just to say hi! Don't forget to join the forum for more engaging discussions and stay updated with the latest blog posts. Let's keep the conversation going and make cybersecurity a community effort!

-AJ