The Vercel Breach Explained: How a Game Download Led to a Supply Chain Attack on 580 Employees

What Happened

On April 19, 2026, Vercel: the platform behind Next.js and one of the most widely used deployment platforms for web developers: disclosed a security breach. The attacker gained unauthorized access to internal Vercel systems and exfiltrated a limited set of environment variables and employee data. On BreachForums, someone claiming to be affiliated with the ShinyHunters group listed the stolen data for $2 million.

Update, June 2026: Vercel's public bulletin was last updated on April 24, 2026. Vercel says it notified affected customers, identified a small number of additional compromised accounts during the continued review, and confirmed with GitHub, Microsoft, npm, and Socket that Vercel-published npm packages were not compromised.

The root cause was not a Vercel vulnerability. It was a compromised third-party AI tool called Context.ai that a Vercel employee used: a textbook supply chain attack.

Vercel described the attacker as "highly sophisticated based on their operational velocity and detailed understanding of Vercel's systems." Within hours of gaining access, they had enumerated environment variables and pivoted laterally to expand their footprint.

The Full Attack Chain

The breach unfolded across four stages over roughly two months before Vercel detected it.

Stage 1: Infostealer Infection at Context.ai (February 2026)

A Context.ai employee downloaded what appeared to be game exploits or cracked software. The files were laced with Lumma Stealer, a commodity infostealer sold as a service on cybercrime forums. Lumma silently harvested the employee's stored credentials, including Google Workspace credentials and authentication tokens for several connected applications.

This single infected machine became the entry point for everything that followed.

Stage 2: Malicious Browser Extension Deployment

Armed with Context.ai employee credentials, the attacker accessed the Context.ai environment and distributed a malicious Chrome extension. The extension: Chrome Extension ID omddlmnhcofjbnbflmjginpjjblphbgk: was crafted to appear legitimate and requested OAuth consent for full Google Drive read access during installation.

The extension was eventually removed on March 27, 2026, but by then it had already been installed by at least one Vercel employee.

Stage 3: Google Workspace Takeover and Vercel Pivot

When the Vercel employee installed the extension and approved the OAuth consent, the attacker gained read access to their Google Drive. This foothold was used to access the employee's Google Workspace account: the same identity used to authenticate into Vercel's internal systems. From there, the attacker pivoted into Vercel's environment.

Stage 4: Enumeration, Lateral Movement, and Exfiltration

Inside Vercel's environment, the attacker targeted non-sensitive environment variables: those not flagged as sensitive in the Vercel dashboard, and therefore stored in plaintext rather than encrypted at rest. They enumerated these variables and used the discovered credentials (API keys, tokens) to expand access further.

Vercel confirmed the attacker accessed and likely exfiltrated:

• Non-sensitive environment variables from a limited subset of customer projects
• 580 employee records (names, Vercel email addresses, account status, activity timestamps)

The threat actor claimed to also have source code, database credentials, npm tokens, and GitHub tokens: though Vercel and a collaborative investigation with GitHub, Microsoft, npm, and Socket found no evidence of npm package tampering and confirmed that Next.js, Turbopack, and all Vercel open-source projects remain uncompromised.

What Was (and Was Not) Compromised

Indicators of Compromise (IOCs)

If you are a Google Workspace administrator or a Vercel customer, check for these immediately.

Malicious Chrome Extension

• Extension ID: omddlmnhcofjbnbflmjginpjjblphbgk
• Requested full Google Drive read access via OAuth
• Was distributed through the Context.ai ecosystem

Malicious OAuth Application

• Google OAuth Client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
• Check your Google Workspace Admin Console under Security > API Controls > App Access Control for this client ID
• Revoke access immediately if found

Immediate Actions for Vercel Users

Vercel published official guidance, and these are the steps you should take today, not this week.

1. Rotate All Non-Sensitive Environment Variables

Any environment variable not marked as "sensitive" in your Vercel project settings should be considered compromised and rotated immediately. This includes:

• Third-party API keys (analytics, CMS, email providers, payment processors)
• Webhook secrets
• Feature flag tokens
• Any public-facing integration credentials

To rotate, go to your Vercel project dashboard, navigate to Settings > Environment Variables, delete and recreate each non-sensitive variable, then redeploy.

2. Enable MFA on Your Vercel Account

If you are not already using an authenticator app or passkey for your Vercel account, enable it now. SMS-based MFA is not sufficient against sophisticated actors: use TOTP (Google Authenticator, Authy) or a hardware key.

3. Audit Your OAuth-Connected Apps

Review every third-party application with OAuth access to your Google Workspace or GitHub account. Remove anything you do not actively recognize or use. In Google Workspace Admin, check Security > API Controls > Manage Third-Party App Access.

4. Audit Chrome Extensions Across Your Team

Extensions run in a privileged browser context and have access to everything your browser sessions touch. Audit installed extensions on developer machines and enforce an allowlist policy if your organization has the means to do so. Any extension with broad OAuth scopes (especially Google Drive read) deserves scrutiny.

5. Review Account Activity and Recent Deployments

Check your Vercel account activity log for any logins or deployments you do not recognize. Review the audit log in your team settings. If you find anomalies, rotate all credentials immediately and contact Vercel support.

6. Enable and Rotate Deployment Protection Tokens

Enable Deployment Protection at Standard level or above, and rotate your existing Deployment Protection tokens. This limits who can trigger deployments on your behalf.

The Bigger Picture: Why This Breach Pattern Is Becoming Common

The Vercel breach is not an isolated incident. It is a template. The same pattern has played out at Okta (2023, via Sitel), CircleCI (2023, via malware on an engineer's laptop), and Snowflake (2024, via stolen credentials from customer machines). The common thread:

1. A third-party vendor or employee's personal machine is infected
2. Credentials or session tokens are harvested by an infostealer
3. Those credentials provide access to a high-value platform
4. The attacker moves laterally using legitimately obtained tokens, bypassing most detection

What makes 2026 different is the AI tool angle. Developers are now connecting an ever-expanding set of AI assistants, copilots, and productivity tools: each with OAuth access to Google Drive, GitHub, Slack, Notion, and more. Each of those connections is a potential entry point.

Environment Variable Security: A Practical Hardening Guide

The core technical damage in this breach came from environment variables stored in plaintext. Here is how to harden your approach.

Mark Every Secret as Sensitive in Vercel

In the Vercel dashboard, any environment variable containing a secret: API keys, tokens, passwords, connection strings: should be marked as "Sensitive." This encrypts the value at rest and prevents it from being read back through the API or UI, even by authenticated sessions.

Use a Secrets Manager for Production Secrets

Rather than storing secrets directly in Vercel environment variables, reference them from a dedicated secrets manager at runtime:

• Azure Key Vault for Azure-integrated stacks
• AWS Secrets Manager or Parameter Store for AWS-integrated stacks
• HashiCorp Vault for multi-cloud environments
• Doppler or Infisical as developer-friendly options

This way, even if an attacker accesses your deployment environment, they get a reference to a secret, not the secret itself.

Scope API Keys to Minimum Permissions

Every API key stored in your environment should have the minimum permissions required for its purpose. A read-only analytics key should not have write access. A CMS preview key should not be able to publish content. Scope everything.

Set Expiry and Rotation Schedules

Secrets should not live forever. Set expiry dates on API keys where the provider supports it, and implement automated rotation (AWS Secrets Manager and Azure Key Vault both support this natively).

OAuth and Browser Extension Risk: What Security Teams Miss

The attack vector here: a Chrome extension with broad OAuth scope: is chronically under-managed in most engineering organizations. Here is what to do about it.

Audit and Restrict Chrome Extension Permissions

For individual developers: review every extension in chrome://extensions. Look for anything with access to "Read and change all your data on websites you visit" or broad Google/GitHub OAuth scopes. Remove anything unnecessary.

For security teams: use browser management policies (Chrome Enterprise, Jamf, Intune) to enforce extension allowlists on corporate devices. Only approved extensions should be installable.

Treat OAuth Consent as a Security Decision

When a tool asks for Google Drive read access, ask: does a dev productivity tool actually need to read all of my Drive? In many cases the answer is no: the scope is over-requested for convenience. Deny broad scopes and see if the tool still works with narrower ones.

Monitor Third-Party App Access Continuously

Google Workspace and Microsoft 365 both provide OAuth audit logs. Set up alerts for new OAuth application grants, especially those requesting broad scopes like Drive read, Gmail read, or repository access.

Supply Chain Risk: Vetting the Tools Your Team Uses

Vercel was breached not because of a flaw in their platform but because of a tool their employee used. The same risk exists in every engineering team.

Evaluate the Security Posture of AI Tools Before Adopting Them

Before your team adds a new AI productivity tool: coding assistant, documentation tool, meeting summarizer: ask:

• What OAuth permissions does it request?
• Does the vendor have a published security policy and incident response process?
• Have they had previous incidents?
• Do they undergo third-party security audits (SOC 2, ISO 27001)?

Limit the Blast Radius of Any Single Tool

If Context.ai had been limited to read access on specific folders rather than all of Google Drive, the lateral movement would have been much harder. Apply least privilege to tool OAuth grants just as you would to service accounts.

Include Third-Party Tools in Your Incident Response Plan

When a third-party vendor is breached, you need to know immediately which of your employees used it and what access it had. Maintain an inventory of every OAuth-connected tool across your team, including the scopes granted.

What Vercel Is Doing Now

According to Vercel's incident bulletin, they:

• Worked with incident response experts and law enforcement
• Identified and notified the limited subset of customers whose non-sensitive environment variables were compromised
• Expanded review with additional IOCs and found a small number of additional compromised accounts
• Confirmed with GitHub, Microsoft, npm, and Socket that Vercel-published npm packages were not compromised
• Recommended rotating environment variables that were not marked sensitive, reviewing activity logs, checking recent deployments, and enabling MFA
• Shipped product enhancements around environment variable management, team-wide security overview, and activity log usability

The public bulletin moved to an ad hoc update cadence after April 24, 2026. Follow Vercel's official bulletin for any later confirmed updates.

Key Takeaways

The Vercel breach is a case study in how modern supply chain attacks work: attackers no longer need to find a zero-day in your platform. They find a weak link in your ecosystem: a third-party tool, a browser extension, a contractor's laptop, and use legitimate credentials to move through your environment invisibly.

For developers and security teams, the lesson is clear: your attack surface includes every tool your team has authorized. OAuth consent is not a formality. Environment variables are secrets, even the "non-sensitive" ones. And infostealer malware on one machine: anywhere in your supply chain: can cascade into a breach at a company serving millions of developers.

The Vercel platform itself was not the vulnerability. The humans and tools around it were.

---

Frequently Asked Questions

What is Lumma Stealer and how did it enable the Vercel breach?

Lumma Stealer is an infostealer malware sold as a criminal subscription service that, when executed on a victim's machine, harvests browser cookies, saved passwords, session tokens, and crypto wallet data and exfiltrates them to the attacker's infrastructure. In the Vercel breach, a Context.ai employee downloaded game-related files in February 2026 that included Lumma Stealer. The malware harvested Google Workspace credentials and OAuth tokens from the employee's browser, giving attackers access to Context.ai's systems without needing to break any encryption. Infostealer malware is the dominant initial access vector for supply chain attacks in 2026 precisely because it bypasses authentication by stealing valid sessions.

What is a supply chain attack and how does the Vercel breach illustrate it?

A supply chain attack targets an organization not by attacking it directly but by compromising a vendor, partner, or tool that the target trusts. In the Vercel breach, attackers did not find a vulnerability in Vercel's platform. Instead they compromised Context.ai, a third-party AI tool that a Vercel employee used, and then used the stolen credentials from Context.ai to access Vercel's internal systems. The attack chain: malware on a contractor's machine, to stolen credentials, to access at a vendor, to lateral movement into the primary target. The Vercel platform's own security was not the weak link; the trust relationship with a third-party tool was.

What should Vercel developers do to secure their projects following this breach?

The immediate actions Vercel recommended are: rotate all environment variables in your Vercel projects, particularly any that were not marked as sensitive (sensitive variables were encrypted at rest and not accessible to the attacker), enable MFA on your Vercel account if not already enabled, review your deployment activity logs for any unexpected activity, and audit which team members have access to your projects and environment variables. For ongoing security: regularly audit OAuth-connected tools your team uses and remove those that are not actively needed, use Vercel's environment variable sensitivity settings correctly (mark secrets as sensitive), and review Vercel's team-wide security overview feature that was shipped after the incident.

How should engineering teams manage OAuth-connected third-party tool risk?

Before authorizing any new third-party tool, review the OAuth scopes it requests and deny any scope that is broader than the tool's function requires. Maintain an inventory of every OAuth-connected tool across the team, including the scopes granted and when each was authorized. Set up alerts in Google Workspace or Microsoft 365 for new OAuth application grants, especially those requesting broad scopes. Periodically review the authorized applications list and revoke access for tools that are no longer actively used. When an incident occurs at a third-party vendor, you need to be able to immediately identify what access that vendor had to your systems and revoke it.

What is the difference between sensitive and non-sensitive environment variables in Vercel, and why does it matter for security?

In Vercel, environment variables marked as sensitive are encrypted at rest using envelope encryption and are never exposed in plaintext through the Vercel API or dashboard after creation. Non-sensitive environment variables are stored in a way that allows them to be read back through the API by authorized users and integrations. In the breach, the attacker's access to Vercel's systems allowed them to read non-sensitive environment variables. Developers should mark any environment variable containing credentials, API keys, secrets, database connection strings, or any value that would enable access to another system as sensitive. The marking cannot be changed after creation; when in doubt, mark as sensitive.