Vercel Breach 2026: AI Tool OAuth, Lumma Stealer, and the Secrets Problem

How a third-party AI tool compromise reached Vercel, why OAuth tokens are now part of the software supply chain, and what the April 2026 incident reveals about secrets management in modern developer infrastructure.

One detail in the Vercel incident explains why this story matters beyond a single vendor: the confirmed breach path never touched Vercel's perimeter. Vercel says it started with a compromise of Context.ai, a third-party AI tool that one Vercel employee happened to use, and that the attacker rode that access into the employee's Google Workspace account before pivoting into Vercel systems.

Separate reporting and infostealer research trace the Context.ai compromise back to Lumma Stealer activity and a Roblox exploit download. That part of the story is important — and it demands source discipline: Vercel has confirmed the Context.ai and Google Workspace pivot; the game-cheat/Lumma origin comes from external incident reporting and malware intelligence.

The confirmed blast radius is narrower and more precise than the early headlines. Vercel says attackers reached certain internal systems and were able to enumerate and decrypt non-sensitive environment variables. Vercel also says its investigation with GitHub, Microsoft, npm, and Socket found no compromise of Vercel-published npm packages.

Vercel published its security bulletin on April 19, 2026 and kept updating it through April 24, 2026. The company identified a limited subset of affected customers, notified them, then surfaced a small number of additional accounts as its IOC review widened.

This article walks through the incident technically, but keeps the attribution clean: official Vercel findings first, external reporting clearly labeled, and then the part that outlasts the news cycle — what this means for how developers handle secrets.

Latest Confirmed Status

As of the April 24, 2026 Vercel bulletin:

• The incident originated with Context.ai, a third-party AI tool used by a Vercel employee.
• The attacker used that access to take over the employee's individual Vercel Google Workspace account, then pivoted into a Vercel environment.
• Vercel says the attacker enumerated and decrypted non-sensitive environment variables.
• Vercel identified a limited subset of affected customers, then a small number of additional accounts during expanded IOC review.
• Vercel says separate customer compromises found during the review do not appear to have originated on Vercel systems.
• Vercel says no npm packages published by Vercel were compromised.
• Vercel shipped product enhancements around environment variable management, team-wide security visibility, and activity logs.

Read that list again and notice what kind of story this is. It is not "hosting provider got hacked." It is a story about how AI productivity tools, OAuth grants, Google Workspace identity, and deployment secrets have quietly fused into one connected attack surface.

Why Vercel Is Worth Caring About

A little context before going deep.

Vercel is not just a hosting provider. It is load-bearing infrastructure for a sizable slice of the modern web: the deployment platform behind applications built by millions of developers, the primary maintainer of Next.js — one of the most downloaded JavaScript frameworks on the planet — and the trusted custodian of production secrets for a long list of companies including, famously, OpenAI, Cursor, Pinterest, and Bose.

Using Vercel usually means parking database credentials, API keys, signing secrets, webhook tokens, and deployment configuration in its environment-variable system. The npm packages Vercel maintains ship everywhere across the JavaScript ecosystem. Had those packages been tampered with, the cascade would have been enormous.

The good news is unambiguous: Vercel confirmed the npm supply chain is clean, validated in collaboration with GitHub, Microsoft, npm, and Socket. No evidence of tampering with anything Vercel publishes.

The hard lesson is everything else — because everything else in this story is about how trust actually works in an ecosystem stitched together from third-party integrations.

Understanding Supply Chain Attacks

Before walking the chain hop by hop, it pays to understand the attack category.

A supply chain attack does not hit the victim directly. It hits something the victim trusts. The logic is brutally simple: large companies pour money into their own perimeter — security teams, intrusion detection, monitoring, hardened infrastructure. A frontal assault is expensive and usually fails.

But every company also trusts vendors, tools, services, and third-party integrations, and each of those third parties runs its own perimeter — often a far softer one. Compromise a trusted third party and you inherit whatever access its customers have granted it. You do not need to break through the wall when you hold a key to the side door.

That is why supply chain attacks have become one of the dominant breach categories of the past decade. The canonical example is SolarWinds (2020), where attackers subverted a software update system and reached thousands of organizations in one move. The pattern has only accelerated since.

The Vercel breach is a textbook case — with a distinctly 2026 twist. The supply chain here is not a build system. It is an OAuth integration between AI productivity tools. And the key to the side door was a token, not a password.

Act I — Lumma Stealer, Explained

To understand how a Roblox script set all of this in motion, you need to understand what Lumma Stealer actually is.

The Business Model of Malware

Lumma Stealer (also known as LummaC2) was not written by a lone hacker in a basement. It is a commercial product — a Malware-as-a-Service (MaaS) operation, developed and maintained by a Russian-speaking threat actor operating under the alias "Shamel," tracked by Microsoft's Threat Intelligence division as Storm-2477.

Lumma sold through subscription tiers running from $250 to $1,000 per month, with source code access priced at $20,000. The cheap tiers get basic log filtering and download options. The expensive ones add custom data collection configurations, better evasion, and early access to new features. The top tier — the source code — lets a customer build a derivative and resell it.

In a November 2023 interview with security researcher "g0njxa," Shamel claimed "about 400 active clients." He built Lumma an actual brand: a bird logo he described as a symbol of "peace, lightness, and tranquility," and a slogan — "making money with us is just as easy."

This is a business. Customers, support tiers, marketing, a changelog. The barrier to entry is deliberately low, because the goal is volume, not sophistication.

What Lumma Does on Your Machine

The first thing Lumma does on a Windows machine is fingerprint it: OS version, hardware ID, CPU, RAM, screen resolution, system language. Not out of curiosity — out of caution. It is checking whether it woke up inside a sandbox or an analyst's VM. If it did, it exits quietly and does nothing. The evasion is built into the core.

Once it decides the machine is real, the collection routines run. Here is what it actually takes:

From browsers (Chrome, Edge, Firefox, Brave, Opera, and others):

The valuable browser data lives in a handful of well-known places. Chrome keeps passwords in an SQLite database called Login Data and cookies in another called Cookies. The values are encrypted — and here is the catch.

Historically, Chrome relied on Windows DPAPI (Data Protection API), which encrypts data with a key derived from the user's Windows login. DPAPI protects data between users — not between processes. Any process running as the logged-in user can call CryptUnprotectData() and walk away with the plaintext. So Lumma, running as the current user — because the current user downloaded and ran it — decrypts Chrome's entire password and cookie store trivially.

Google shipped App-Bound Encryption in Chrome 127 (July 2024) precisely to close this hole. The new scheme routes decryption through a privileged Windows service running as SYSTEM, which checks that the requesting process really is Chrome before handing over the key. In theory, user-level malware is locked out.

App-Bound Encryption went live on July 30, 2024. Security researchers observed evidence of bypass capabilities by September 12, 2024. Less than 45 days.

Beyond browsers:

Lumma also hunts for cryptocurrency wallets and extensions — wallet files, browser extensions, and local keys for MetaMask, Electrum, Exodus and the like. Its target list comes down from the active C2 server as configuration: crypto, browsers, VPN configurations, email clients, FTP clients, Telegram session data, SSH keys, .env files, password manager data, user documents.

The output of an infection is a structured archive — a "log," in infostealer parlance — uploaded in real time to the attacker's C2 infrastructure. A single log can hold hundreds of credentials, dozens of session cookies, and OAuth tokens for every web service the victim was signed into.

How Lumma Gets Distributed

Lumma's operators are the model of the modern multi-vector campaign: fluent impersonation, malicious domains rotated constantly, ad networks abused, legitimate cloud services pressed into service to dodge detection.

In the Context AI employee's case, the delivery vector was a Roblox exploit tool. A game cheat — one of the oldest tricks in the book, and still one of the best. Someone downloading a game cheat has already decided to ignore the security warnings, has often already disabled the security tooling, and has mentally switched into "take a risk" mode. The victim supplies their own justification for bypassing every defense.

The Disruption and the Comeback

Between March 16 and May 16, 2025, Microsoft counted over 394,000 Windows machines infected by Lumma worldwide. Working with law enforcement and industry partners — Europol, the FBI, ESET, BitSight, Cloudflare, and others — Microsoft's Digital Crimes Unit filed civil action and seized roughly 2,300 malicious domains, the backbone of Lumma's infrastructure.

A heavy blow. Not a fatal one.

Activity started recovering within weeks, and by late 2025 into early 2026 campaigns were climbing again globally. The Context AI employee's machine was infected in February 2026 — about nine months after the takedown. Lumma had rebuilt.

That is the nature of MaaS. You can seize the infrastructure. The developer, the code, and the affiliate base walk away.

Act II — The OAuth Bridge

The Lumma infection handed the attacker a credential dump from the Context AI employee's machine. In it: Google Workspace credentials for the employee's work account, credentials for support@context.ai — identified by Hudson Rock's analysis as a core team account — and API keys for Supabase, Datadog, and Authkit.

OAuth: The Protocol That Replaced Passwords (And Created New Problems)

OAuth exists to solve a real problem: how do you let Application B touch your data in Service A without handing Application B your Service A password?

The OAuth 2.0 flow issues two tokens once the user authorizes:

• An access token: short-lived (typically 60 minutes), used directly in API calls
• A refresh token: long-lived, used to mint new access tokens without re-prompting the user

Why Refresh Tokens Are the Real Attack Surface

Refresh tokens are bearer credentials — whoever holds one can use it, no further identity check required. The user completed the OAuth consent flow with MFA once; the resulting refresh token carries that authorization forward indefinitely, no re-authentication needed.

"Bearer credential" means exactly what it sounds like. Possession equals authorization. No second factor, no device binding, no IP verification. Hold the token and, as far as the resource server is concerned, you are the authorized party.

The implication is the one most people get wrong: MFA does not protect against refresh token theft. The MFA happened when the user originally authorized the app. The token is the receipt of that past authorization. An attacker who steals it has no need to re-authenticate — the authentication already happened, and the token is the proof.

Worse: most SaaS apps do not invalidate existing refresh tokens when a password is reset or MFA settings change. An attacker holding stolen refresh tokens keeps their access straight through the standard incident-response playbook — until those specific tokens are explicitly revoked.

Context AI's OAuth Position

Context AI is an AI Office Suite. It connects to your Google Workspace, reads your documents, email, and calendar, and layers AI assistance on top. To do that, it stores refresh tokens for every user who authorizes it. Those tokens live on Context AI's servers.

The attacker, now holding the support@context.ai credentials, walked into Context AI's systems. Inside: refresh tokens for every connected Google Workspace account.

Vercel is not a Context customer. But at least one Vercel employee appears to have signed up for the AI Office Suite with their Vercel enterprise account — and granted "Allow All" permissions. Sit with that phrase: "Allow All." Maximum scope. An OAuth token at that permission level hands its holder essentially the whole connected Google account.

The attacker found that token in the Context AI database and used it. Google's systems saw a valid, legitimately issued refresh token. No alarm fired.

Act III — Inside Vercel

From the employee's Google Workspace account, the attacker had a foothold in corporate Google infrastructure — and, depending on how single sign-on was wired, a potential path into any internal tool that authenticates via Google.

Vercel assessed the attacker as highly sophisticated, based on their speed and their detailed understanding of Vercel's systems. They moved fast and precisely. They knew what they were looking for.

What they found: environment variables.

The Sensitive vs. Non-Sensitive Problem

Vercel offers two storage modes for environment variables:

Sensitive variables are encrypted at rest with a mechanism that makes the value unreadable after storage — not by Vercel's systems, not by users in the dashboard, not by an attacker with internal access.

Non-sensitive variables are stored in readable form. Systems with the right internal access can retrieve the plaintext. That is what lets the dashboard show you a variable's value — and it is also what lets an attacker with internal access read it.

Vercel confirms the attacker accessed non-sensitive environment variables. Some external reports claimed additional data categories; the operational guidance here anchors on the confirmed exposure: readable secrets must be treated as potentially compromised and rotated at the source.

After the incident, Vercel pointed to product work on stronger environment-variable defaults, team-wide variable management, improved safeguards, in-product education, and denser activity-log tooling. The direction is right. A secret that never needs to be read back should never be readable from routine product surfaces.

The Full Kill Chain, Assembled

February 2026
├── Context.ai employee downloads Roblox exploit tool on work/personal laptop
└── Lumma Stealer (MaaS, Storm-2477, ~$250-$1,000/month rental) executes

Lumma harvests:
├── Browser cookies and saved passwords (DPAPI/App-Bound Encryption bypass)
├── Google Workspace credentials (work email, `support@context.ai` account)
├── API keys: Supabase, Datadog, Authkit
└── OAuth tokens stored by desktop/browser applications

Attacker receives credential log. Pattern-matching reveals:
└── `support@context.ai` = elevated access inside Context AI's Vercel team

Attacker uses support@context.ai account:
├── Accesses Context AI's AWS environment (March 2026 per Context AI's disclosure)
└── Extracts OAuth refresh tokens for connected Google Workspace users

Inside the token harvest:
└── Refresh token for Vercel employee's Google account ("Allow All" scope)

Attacker presents stolen refresh token to Google's API:
├── Google issues fresh access token (no MFA required — token IS the proof of auth)
└── Attacker has full access to Vercel employee's Google Workspace

From employee's Google Workspace:
├── SSO pivot into Vercel internal tools
├── Access to environments and non-sensitive environment variables
└── Enumeration/decryption of non-sensitive environment variables

April 19, 2026: Vercel discloses incident
April 20-24, 2026: Vercel expands guidance, confirms npm packages are not compromised, and ships product enhancements
April 27, 2026: This article updated

Four hops, in the cleanest version of the story: third-party AI tool compromise, Google Workspace takeover, internal environment access, readable secrets. The point is not whether every external detail is proven. The point is that OAuth tokens can turn a small vendor compromise into access inside a much larger customer's identity perimeter.

The Part About AI Tools Specifically

Now for the uncomfortable structural truth this breach exposes.

Every AI productivity tool you connect to your Google Workspace asks for broad OAuth scopes, because broad access is the product. An AI email assistant has to read your email. An AI meeting summarizer needs your calendar. An AI document tool needs your Drive. You cannot build these products on narrow scopes. The scopes are the product.

Which creates a structural bind: the more useful the tool — the deeper it sits in your work context — the broader the access it demands. And the broader the access, the more catastrophic the blast radius on the day its OAuth tokens leak.

There is no tidy solution here. What you can do is name the trust relationship honestly. When you click "Allow" on a Google permission screen for an AI tool, you are not granting access to your documents. You are granting access to whoever ends up controlling that tool's servers. That is the accurate framing.

The Salesloft-Drift Precedent Nobody Talked About

The Vercel breach did not come out of nowhere. There is a direct 2025 precedent that the developer community mostly slept through.

In August 2025, threat actor UNC6395 used stolen OAuth tokens from Drift's Salesforce integration to reach customer environments across more than 700 organizations. No exploit. No phishing. The attacker got into Salesloft's GitHub in March 2025, then leveraged Drift integration OAuth tokens to access Salesforce instances across hundreds of customer organizations. The full exfiltration chain: Compromised GitHub account → Drift's AWS environment → Extracted OAuth tokens → Custom Python scripts queried customer Salesforce instances → Exfiltrated contacts, opportunities, AWS keys, Snowflake tokens.

One integration. Seven hundred organizations breached. The Vercel incident is the same pattern, replayed one layer down the stack — in developer tooling. Context AI is to Vercel what Drift was to those 700 Salesforce organizations.

What You Should Actually Do

Enough analysis. Here is the actionable part.

Immediate Actions (Today)

The IOC to Check Now

If you administer a Google Workspace, look for this OAuth app among your authorized apps:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

If it is there, revoke it immediately.

The Scope Minimization Principle

Before clicking "Allow" on any new AI tool, read the scopes it is asking for — and ask whether it actually needs them. Broad scopes buy broad blast radius.

Where you can, connect AI productivity tools to purpose-specific Google accounts rather than your main corporate identity. Yes, it adds friction. It also means that when that account's token leaks, the attacker does not inherit your corporate email, your sensitive documents, and your admin systems along with it.

Token Lifecycle Management

OAuth tokens should not be forever. The relevant best practices from RFC 9700 (published January 2025):

• Refresh token rotation: every use of a refresh token should invalidate it and issue a replacement.
• Appropriate token lifetimes: for sensitive APIs, refresh tokens should expire within 7-30 days.
• Token inventory: keep a register of the OAuth apps your organization has authorized — and put it in your offboarding checklist.

The Deeper Lesson

Here is the thought I keep coming back to as I read through the technical details.

Every link in this attack chain — the Lumma infection, the OAuth handshake, the token storage, the Google Workspace pivot — was working exactly as designed. Lumma did what infostealers do. OAuth issued tokens the way OAuth issues tokens. Google honored a valid refresh token. Vercel stored environment variables the way it always had.

Everything worked as designed. That is precisely why the attack worked.

There was no bug to patch that would have stopped this. The attack lived in the gap between what the technology does and what its users assume it does. People assume OAuth is safe because they used MFA when they set it up. They assume their credentials are protected because they use a password manager. They assume that someone who does not know their password cannot get into their account.

None of those assumptions survives a token that is already sitting in someone else's database.

Status as of April 27, 2026

Vercel moved the bulletin to an ad hoc update cadence after April 24. The investigation and remediation involved Google Mandiant, additional cybersecurity firms, industry peers, law enforcement, and direct engagement with Context.ai.

For developers, the most important confirmed point is that Vercel's npm package supply chain was not compromised. The most important operational point is still rotation: any value not marked sensitive should be treated as potentially exposed if your account was notified — or if your own logs show suspicious access.

If you use Vercel, the checklist above is not optional. Do it today.

And if you are thinking "we're too small, this won't happen to us" — that misreads the shape of the risk. Small AI tools hold refresh tokens, workspace grants, support credentials, and integration access that much larger customers depend on. The attacker does not need to pick you first. They follow whichever credential chain turns out to be useful.

This threat model is not targeted. It is opportunistic and systematic.

Updated April 27, 2026. Primary source: Vercel security bulletin. Supporting context: Microsoft Lumma analysis, TechCrunch, Hudson Rock, CyberArk C4 Attack, ITECS analysis, and Obsidian Security. External reporting is treated as context unless confirmed by Vercel.