Hardenly
Blog
Get Started
HomeSecurity IntelThe Vercel Breach Wasn't a Vercel Problem
vercelsecurity breachsupply chain attackenvironment variablesincident response

The Vercel Breach Wasn't a Vercel Problem

April 20, 2026

On this page

Table of Contents

The Vercel Breach Wasn't a Vercel ProblemThe Attack ChainWho Actually Did This?What Was ExposedScope Is ExpandingWhy This Is InterestingWhat Vercel Customers Should DoThe Bigger QuestionTimelineIndicators of CompromiseReferences

The Vercel Breach Wasn't a Vercel Problem

Updated April 25, 2026 with new details on the attack vector, disputed attribution, and expanded scope.

On April 19, 2026, Vercel published a security bulletin disclosing unauthorized access to internal systems. A threat actor posted on BreachForums under the ShinyHunters name, listing the stolen data for $2 million.

The interesting part isn't that Vercel got breached. It's how.

The attacker didn't find a vulnerability in Vercel's infrastructure. They didn't exploit a misconfigured server or an unpatched dependency. They compromised a third-party AI tool called Context.ai that Vercel employees used internally — and rode that access into Vercel's systems.

Three hops. That's all it took.

The Attack Chain

Here's where it gets absurd.

According to OX Security, the Context.ai employee who got compromised was downloading Roblox "auto-farm" scripts and executors — notorious vectors for Lumma stealer deployments. That's how the malware got in. A Roblox cheat download.

From there, the chain looked like this:

  1. The Lumma infostealer silently exfiltrated passwords and session tokens from the Context.ai employee's machine (February 2026).
  2. Context.ai had a Chrome extension (ID: omddlmnhcofjbnbflmjginpjjblphbgk) that requested OAuth2 access to Google Drive with full read permissions. The attacker used the stolen credentials to pivot through this OAuth access into a Vercel employee's Google Workspace account.
  3. From Google Workspace, they accessed internal Vercel systems and enumerated and decrypted customer environment variables — every one that wasn't marked "sensitive."

The Chrome extension was removed on March 27, 2026. If you want to check whether your org was affected, the Google App ID associated with the compromised OAuth application is 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com.

Who Actually Did This?

This part is still murky. The BreachForums post was made under the ShinyHunters name — a well-known cybercriminal group that's been active since 2020. But BleepingComputer reports that ShinyHunters told them directly they're not involved.

So either someone impersonated ShinyHunters for credibility on the forum, or there's more to the attribution story. Either way, the $2 million listing is real and the data appears genuine.

What Was Exposed

Vercel's environment variables have a "sensitive" toggle. When enabled, the value is encrypted and can't be read back from the dashboard or API. When not enabled, the value is accessible from internal systems.

The attacker accessed the non-sensitive ones. That could include:

  • Database connection strings
  • API keys (Stripe, OpenAI, AWS, etc.)
  • Auth secrets, JWT keys, OAuth credentials
  • Any token stored as a plain environment variable

They also grabbed 580 Vercel employee records — names, emails, account status, and activity timestamps. And they claim to have source code, NPM tokens, and GitHub tokens, though Vercel hasn't confirmed that.

Vercel says environment variables marked "sensitive" were encrypted at rest and there's no evidence they were accessed. Guillermo Rauch also confirmed that Next.js, Turbopack, and Vercel's open-source projects are clean. Vercel collaborated with Microsoft, GitHub, npm, and Socket to verify that none of their npm packages were compromised.

Scope Is Expanding

Initially, Vercel said a "limited subset of customers" were affected. Since then, they've found a small number of additional compromised accounts. They also identified some customer accounts with signs of compromise that appear separate from the April incident — meaning these don't appear to have originated from Vercel's systems at all.

If you never toggled the "sensitive" flag on your environment variables, it's worth checking.

Why This Is Interesting

I've been thinking about this from a threat modeling perspective.

Vercel is a well-funded company with a serious security team. They engaged Mandiant for incident response. Their "sensitive" environment variable feature — the one that saved encrypted secrets from exposure — shows they thought about this class of risk.

But the attack didn't target any of that. It targeted a Chrome extension from an AI tool that an employee had authorized. Context.ai's extension requested full read access to Google Drive via OAuth. That's a lot of access for a third-party AI tool.

And the initial infection vector wasn't some advanced exploit. It was an employee downloading game cheats. OX Security notes this isn't a one-off — it's the same pattern seen in the Axios, Trivy, and Shai Huluid attacks in the past year. Compromise a vendor employee, harvest OAuth tokens, pivot laterally across organizations.

Think about it.

How many AI tools does your engineering team use? Copilot, Cursor, various ChatGPT plugins, internal AI assistants, analytics tools like Context.ai. Which ones have OAuth access to your org's Google Workspace, GitHub, or Slack? Most teams can't answer this question.

What Vercel Customers Should Do

If you're on Vercel and your environment variables aren't marked "sensitive," rotate them. Database passwords, API keys, auth secrets — the usual suspects.

When re-adding them, enable the "sensitive" toggle this time:

  1. Go to Settings > Environment Variables
  2. Click the options menu on each variable
  3. Enable "Sensitive"

Vercel is reportedly defaulting new environment variables to "sensitive" going forward — a platform-level change that directly addresses the root cause of the exposure. But existing variables won't change retroactively, so this is still on you.

Also worth running git log --all -p -S 'YOUR_SECRET_NAME' to check if you ever accidentally committed secrets in your git history. The attacker claims to have accessed source code.

Check your Google Account's third-party app connections for the compromised Context.ai OAuth ID (110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj). And check your third-party dashboards (Stripe, AWS, database providers) for unusual activity — unexpected API calls, unfamiliar IP addresses, keys you didn't create.

OX Security also recommends pinning Vercel-maintained npm packages (Next.js, SWR, Turborepo, AI SDK) to specific versions as a precaution, even though no package compromise has been found.

The Bigger Question

The Startup Fortune headline framed this as "AI Tool Supply Chain Risk." That's accurate but incomplete.

The real question is: who's auditing the AI tools your team uses?

Most companies have processes for vetting infrastructure providers and major SaaS vendors. But AI tools? They get adopted bottom-up. An engineer signs up, grants OAuth access, and starts using it. No security review, no access audit, no offboarding process when the tool is abandoned.

Context.ai was probably one of dozens of tools with some level of access to Vercel's internal accounts. The attacker only needed one. And the weakest link wasn't even at Vercel or Context.ai's infrastructure — it was an employee downloading Roblox cheats on a machine with access to production credentials.

If there's a takeaway here, it's not "Vercel had bad security." It's that every third-party tool with access to your org is part of your attack surface — and the AI tools that employees adopt informally are the ones least likely to be audited.

Timeline

DateEvent
February 2026Context.ai employee infected with Lumma infostealer via Roblox cheat downloads
March 27, 2026Context.ai Chrome extension removed
April 19, 2026Vercel publishes security bulletin
April 19, 2026BreachForums post under ShinyHunters name, lists data for $2M
April 20, 2026Vercel confirms npm packages clean after coordinating with GitHub, Microsoft, npm, Socket
April 20, 2026ShinyHunters denies involvement to BleepingComputer
April 21–25, 2026Vercel finds additional compromised accounts; investigation ongoing with Mandiant

Indicators of Compromise

IOCValue
Context.ai Chrome Extension IDomddlmnhcofjbnbflmjginpjjblphbgk
Context.ai Google OAuth App ID110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

References

  • Vercel April 2026 security incident — Official Bulletin
  • Vercel Breach Tied to Context AI Hack — The Hacker News
  • Vercel confirms breach — BleepingComputer
  • Vercel confirms security incident — CyberInsider
  • Vercel Breached via Context AI Supply Chain Attack — OX Security
  • Vercel Breach Exposes AI Tool Supply Chain Risk — Startup Fortune
  • Vercel Breach Linked to Infostealer at Context.ai — InfoStealers
  • More customer accounts found compromised — News9live
  • ShinyHunters claims theft of internal database — UpGuard
  • Vercel Breach: OAuth Supply Chain Attack — Trend Micro

Related Articles

How to Handle Vercel Security Checkpoint Error

On this page

Table of Contents

The Vercel Breach Wasn't a Vercel ProblemThe Attack ChainWho Actually Did This?What Was ExposedScope Is ExpandingWhy This Is InterestingWhat Vercel Customers Should DoThe Bigger QuestionTimelineIndicators of CompromiseReferences

Quick Security Check

See if your Vercel app has similar vulnerabilities.

Scan Your App

Security Scanner

Don't just read about it—fix it

Scan your Vercel deployment for the vulnerabilities discussed in this article. Free scan, results in 60 seconds.

$

Your scan includes:

  • Exposed secrets detection
  • Security header analysis
  • Server/client boundary checks
  • Step-by-step remediation