One Employee. One OAuth Token. The Vercel Breach Explained

Put the coffee on.

Vercel, the company that hosts your Next.js app, your CI/CD pipeline, your preview deployments, and for a disturbingly large slice of the web development world, your production frontend infrastructure, confirmed a security breach on April 18-19, 2026. The attack chain runs through a third-party AI tool, a compromised infostealer infection from February, a Google Workspace OAuth misconfiguration, and a threat actor who understood Vercel's internal systems well enough that the company called them "highly sophisticated" in their own bulletin.

The attacker is currently selling the data for $2 million on BreachForums.

If you run anything on Vercel and you have not rotated your environment variables in the past 48 hours, stop reading this and go do that first. Then come back.

Are you enjoying what you are reading so far? Our staff of writers recommends reading The Axios Crisis: A Critical SSRF Vuln, a North Korean Supply Chain Attack after you finish this one.

The Mental Model: Supply Chain Attacks and OAuth Trust

Before the specifics, you need the model. This attack is not a Vercel hack in the traditional sense. Nobody cracked Vercel's infrastructure directly. The attacker found a weaker link, broke that first, and used the trust relationships that link had already established to walk into Vercel's systems.

This is a supply chain attack. And OAuth is what made it possible.

OAuth is an authorization protocol that lets one application act on behalf of a user in another application, without that user handing over their password. When you click "Sign in with Google" or "Connect your GitHub account," you are granting OAuth permissions. The application gets a token. That token represents a slice of your identity and your access rights. If an attacker steals that token, they do not need your password. They already have what the token authorizes them to do.

The dangerous part is the scope. When a user grants permissions, they sometimes grant broad ones. The Context.ai OAuth app in this breach received "Allow All" permissions on the Vercel employee's Google Workspace account. That employee connected a personal productivity tool to their corporate enterprise account. Standard enterprise Google Workspace settings should have blocked that. They did not.

From that single OAuth token, the attacker reached Vercel's internal environments.

The second piece of the model is Lumma Stealer, the infostealer malware that started this chain. Infostealers are commodity malware. Lumma specifically harvests session cookies, saved credentials, crypto wallets, and browser data from infected machines. Attackers buy access to the logs these tools generate, and the logs contain everything the infected machine touched. One infected developer machine at a small AI startup in February 2026 became the entry point for a breach at one of the internet's most widely used deployment platforms two months later.

That gap, two months between infection and exploitation, tells you something about how patient this attacker was.

The Full Attack Chain

Hudson Rock published a report on April 20 that connected the earlier dots. Here is the full sequence, in order.

February 2026. A Context.ai employee's machine is infected with Lumma Stealer. The malware harvests credentials and exfiltrates them. Among the stolen records: Google Workspace credentials, along with keys and logins for Supabase, Datadog, and Authkit. Also in the haul: the [email protected] account credentials.

That support account matters. Whoever controlled it could interact with customers as if they were Context.ai support. They could access customer logs. They could escalate privileges inside the platform in ways a regular user account could not. The pattern here, stealing a support account to bypass normal access controls, is a textbook move.

March 2026. Context.ai identifies and blocks unauthorized access to its AWS environment. The company publishes a security bulletin describing the incident. At this point they believe the scope is limited. They notify one customer. They do not yet know what they are dealing with.

Meanwhile. The attacker is not done. Context.ai's Office Suite consumer app, a tool that automates workflows across third-party applications, has OAuth tokens for its users. The attacker uses the compromised [email protected] access to get at those tokens. Somewhere in that list of tokens is one belonging to a Vercel employee who signed up for Context.ai's Office Suite using their Vercel enterprise account, and who granted it "Allow All" permissions on their Google Workspace.

Context.ai described this in a statement: the unauthorized actor used a compromised OAuth token to access Vercel's Google Workspace. Vercel itself was not a Context.ai customer. One Vercel employee signed up personally and used their enterprise credentials to do it.

April 2026. The attacker uses that OAuth token to take over the Vercel employee's Google Workspace account. From there, they pivot into Vercel's internal environments. They read environment variables that were not marked as sensitive. They move fast enough that Vercel's own incident report describes the attacker's "operational velocity" as one of the indicators of sophistication.

The breach is discovered. Vercel publishes its bulletin April 18-19.

What Was Actually Exposed

Read Vercel's own bulletin carefully and you find careful language.

Vercel confirmed the attacker accessed "some Vercel environments and environment variables that were not marked as 'sensitive.'" The company says environment variables marked sensitive are stored using encryption in a way that prevents them from being read, and that there is no current evidence those values were accessed.

The distinction between sensitive and non-sensitive environment variables is real and technical. Sensitive env vars in Vercel get encrypted at rest in a way that makes them unreadable even to Vercel's own systems during normal operations. Non-sensitive ones are accessible. If your database password was sitting in a non-sensitive env var, treat it as compromised.

The attacker, posting on BreachForums under a ShinyHunters persona, claims more than that. The forum post claims the stolen data includes customer API keys, source code, database data, NPM tokens, and GitHub tokens. As proof of access, the attacker posted a text file containing 580 Vercel employee records, including names, email addresses, account statuses, and activity timestamps, alongside a screenshot of what appears to be an internal Vercel Enterprise dashboard.

The actual ShinyHunters group, when contacted by BleepingComputer, denied involvement. The threat actor posting on the forum used the ShinyHunters name but the real gang says they did not do this. Identity confusion in the threat actor space is common. Someone is selling the data. The origin of the name on the listing does not change that.

Vercel told TechCrunch the breach may affect "hundreds of users across many organizations," which means the blast radius extends past Vercel's own customers into the downstream users of those customers' applications.

Next.js and Turbopack are unaffected. Vercel confirmed this explicitly. The open source projects were not touched.

The $2 Million Ask

The attacker wants $2 million.

That number is sitting on BreachForums right now. The listing claims the package includes internal database access, API keys, source code, employee account data, and GitHub tokens. In Telegram messages, the attacker also claimed to be in direct communication with Vercel about a ransom demand. Vercel told reporters they had not received any communication from the attacker and were not negotiating.

Two million dollars for a frontend cloud platform's internal credentials is not an unreasonable ask if the data is what the attacker claims. GitHub tokens alone, if they cover internal repositories, could expose unreleased product code, internal tooling, and potentially customer code hosted on the platform. API keys to customer environments could cascade into breaches of the customers' own infrastructure. The value multiplies fast when you are a platform hosting other people's applications.

Whether the attacker gets anywhere near $2 million is a different question. Data like this loses value quickly once it is disclosed and companies start rotating credentials. The window between "breach confirmed" and "credentials are stale" is closing.

The Crypto Blast Radius

This is the part that spread fast.

Vercel underpins frontend infrastructure for a significant portion of Web3 applications. Wallet interfaces. Exchange dashboards. DeFi protocol front ends. Applications where a compromised deployment could serve malicious code to users who then approve transactions thinking they are interacting with a legitimate UI.

Solana-based exchange Orca confirmed their on-chain protocol and user funds were not affected by the breach, but said they were conducting a thorough review. That kind of statement, "on-chain funds are safe," tells you what they were worried about. A compromised frontend at a DeFi application does not need to touch the underlying smart contracts to drain wallets. It just needs to swap out an address in a transaction approval UI.

April 2026 has been a brutal month for crypto already. The Drift protocol lost around $285 million in late March in an attack linked to North Korea-affiliated actors. Smaller protocols have followed. The Vercel breach landing in this environment is not a coincidence that anyone can confirm, but the pattern is hard to ignore. When you attack the infrastructure layer that developers build on top of, you are not targeting one application. You are targeting every application hosted on that infrastructure.

This breach follows the same playbook as the Axios supply chain attack that landed earlier this year. The target is never the platform. The target is the developer tooling ecosystem sitting underneath it.

What You Need to Do Right Now

Vercel published specific recommendations. These are not suggestions.

Rotate every environment variable that was not marked sensitive. If it contains a secret, a database credential, an API key, a signing key, treat it as exposed. Rotate it. Do this before you do anything else.

Enable sensitive environment variables for everything going forward. This feature encrypts values at rest in a way that prevents Vercel's own systems from reading them. If you are not using this, you are relying on access controls alone. This breach demonstrates what happens when access controls fail.

Review your activity log. Go to your Vercel dashboard or run the CLI. Look for deployments or environment accesses you did not make. Look at timestamps. If something looks wrong, delete the deployments in question.

Rotate deployment protection tokens. If you have bypass tokens configured for automated testing or CI pipelines, rotate them.

Check your Google Workspace OAuth apps immediately. Vercel published the IOC: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. If that app has permissions in your Google Workspace, revoke them now. Google Workspace administrators should audit all third-party app authorizations. Not just this one. All of them. If you do not know what OAuth apps have access to your enterprise workspace, finding out is overdue.

Audit your team's personal tool usage. The Vercel employee who installed Context.ai's Office Suite was using a personal consumer app with enterprise credentials. This is how supply chain attacks work. An attacker does not need to breach your organization's approved vendor list. They need to breach something one of your employees installed on their own, connected to their work account, and forgot about.

What Vercel Got Wrong

Vercel describes the attacker as sophisticated. That framing does real work. Calling the attacker sophisticated implies the breach was difficult to prevent.

The access control gap this breach exploited was not subtle. An employee connected a third-party consumer productivity app to their corporate Google Workspace with "Allow All" permissions. Standard enterprise Google Workspace configurations exist precisely to prevent this. Admins can restrict which OAuth apps their users can authorize. They can require admin approval for third-party app authorizations. They can block "Allow All" grant types.

Vercel did not have those controls in place tightly enough to catch this. The attacker's sophistication was in the exploitation speed after gaining access. The entry point itself was a textbook misconfiguration.

The other thing that slipped: Vercel confirmed the breach on April 18-19, but Hacker News users pointed out within hours of the bulletin that Vercel had not sent a broad email notification to its customers. Some customers found out via security news coverage, not from Vercel directly. For a platform hosting production infrastructure for developers and organizations around the world, that communication gap is a problem.

They have since been updating the bulletin and reaching out to confirmed affected customers, but the initial silence is a signal.

The Broader Problem

This breach is three months old by the time it surfaces. The Lumma Stealer infection happened in February. The Context.ai AWS breach happened in March. The Vercel compromise followed. Cybersecurity teams at companies like Vercel are operating on the assumption that their direct vendor relationships are the exposure surface. This attack demonstrates the exposure surface is every employee's personal tool, every consumer app with "Sign in with Google" support, every OAuth token granted and forgotten.

The broader community impact Vercel warned about, "hundreds of users across many organizations," is a consequence of how modern developer infrastructure works. Vercel is not just a hosting company. It is a trust anchor for a significant portion of the web development ecosystem. When that anchor moves, everything attached to it moves too.

This is the second major developer tooling breach this year that traces directly to infostealer malware compromising a vendor's internal credentials. The Anthropic Claude Code source leak via npm followed a similar path. These are not isolated incidents. Someone is systematically targeting the tools developers trust.

Mandiant is on the investigation. Law enforcement is notified. The bulletin is live at vercel.com/kb/bulletin/vercel-april-2026-security-incident and being updated as findings come in.

Watch it. Rotate your credentials. Audit your OAuth apps.

Related reading from the CoderOasis library: The Axios supply chain attack is required reading for understanding how the same infrastructure layer keeps getting targeted. For the AI tool security angle, the Amazon Kiro AI and mass layoffs piece covers what happens when AI tools get handed broad permissions inside engineering organizations. And if you want to understand the specific attack vector that made this breach possible, the new What is OAuth breakdown explains exactly how token-based authorization works and where it breaks.