The Vercel breach: OAuth attack exposes risk in platform environment variables

I'm not sure I've seen it mentioned yet that when Vercel rolled out their environment variable UI, there was no "sensitive" option https://github.com/vercel/vercel/discussions/4558#discussion.... There was ~2 years or more until it was introduced https://vercel.com/changelog/sensitive-environment-variables...

> AI-accelerated tradecraft. The CEO publicly attributed the attacker's unusual velocity to AI augmentation — an early, high-profile data point in the 2026 discourse around AI-accelerated adversary tradecraft.

Attributed without evidence from what I could tell. So it doesn't reveal much at all.

I still don't get how this exactly worked. Is the OAuth Token they talk about the one that you get when a user uses "Sign in with Google"? Aren't they then bound to the client id and client secret of that specific Google App the user signed in to? How were the attackers able to go from that to a control plane? Because even if the attacker knows the users OAuth token, the client id and the client secret, they can access the Google Drive etc. (which is bad, I get that) but I simply do not understand how they could log in into any Vercel systems from that point. Did they find the credentials in the google drive?

"Effective defense requires architectural change: treating OAuth apps as third‑party vendors, eliminating long‑lived platform secrets, and designing for the assumption of provider‑side compromise."

Designing for provider-side compromise is very hard because that's the whole point of trust...

I don't understand Stage 2. Did ContextAI app asked for access to Google mail, drive, calendar, etc? That's crazy. I can't believe any company bigger than a mom and pop shop would agree to run that outside of their own environment.

EDIT: the writeup from context.ai themselves seems quite informative: https://context.ai/security-update, it seems like it was a personal choice of one of the Vercel employees to grant full access to their Google workspace.

There are going to be a lot more like this as the IT-enabled economy at large catch up to the risk debt of broad-based experimentation with AI tools from large and small vendors.

It's "AI-enabled tradecraft" as in let's take a guess at Vercel leadership's pressure to install and test AI across the company, regardless of vendor risk? Speed speed speed.

This is an extremely vanilla exploit that every company operating without a strictly enforceable AI install allowlist is exposed to - how many AI tools like Context are installed across your scope of local and SaaS AI? Odds are, quite a bit, or ask your IT guy/gal for estimates.

These tools have access to... everything! And with a security vendor and RBAC mechanism space that'll exist in about... 18-24 months.

Vercel is the canary. It's going to get interesting here, no way in heck that Context is the only target. This is a well established, well-concerned/well-ignored threat vector, when one breaks open the other start too.

Implies a very challenging 6 months ahead if these exploits are kicking off, as everyone is auditing their AI installs now (or should be), and TAs will fire off with the access they have before it is cut.

Source - am a head of sec in tech

Such an embarrassing way to to get caught.

"The attacker compromised this OAuth application — the compromise has since been traced to a Lumma Stealer malware infection of a Context.ai employee in approximately February 2026, reportedly after the employee downloaded Roblox game exploit scripts"

What bites people: rotating a vercel env variable doesn't invalidate old deployments, because previous deploys keep running with the old credential until you redeploy or delete them. So if you rotated your keys after the bulletin but didn't redeploy everything, then the compromised value is still live.

Also worth checking your Google Workspace OAuth authorizations. Admin Console > Security > API Controls > Third-party app access. Guarantee there are apps in there you authorized for a demo two years ago that are still sitting with full email/drive access.

Vercel did a great job with NextJS and supports quite some OS projects.

But even before AI they had some serious struggles according to long time users.

With the introduction of the deployment platform NextJS appeared to be having advantages being deployed there.

What I can say is that Next has some weird things going on under the hood most senior coders know as “it works, no one knows why, don’t touch these 1.000 LoC here”

Build and runtime settings are a mess. Pre building a docker image on a local machine and deploying it on another turned out to be its Achilles Heel. Weird settings prioritize not as documented, different settings in one area lead to changes in default settings somewhere else. ReactJS server components played a role.

In other words: I sense that while being incredibly useful there might more to come.

It ain’t easy for them, V16 was a rewrite which was API stable. I am not sure about that.

> OAuth trust relationship cascaded into a platform-wide exposure

> The CEO publicly attributed the attacker's unusual velocity to AI

> questions about detection-to-disclosure latency in platform breaches

Typical! The main failures in my mind are:

1. A user account with far too much privileges - possible many others like them

2. No or limited 2FA or any form of ZeroTrust architecture

3. Bad cyber security hygiene

Some of the details in this report, like the timeline beginning in 2024-2025, haven't been widely reported?

Anyone know where these dates are being sourced from? eg,

> Late 2024 – Early 2025: Attacker pivots from Context.ai OAuth access to a Vercel employee's Google Workspace account -- CONFIRMED — Rauch statement

> Early - mid-2025: Internal Vercel systems accessed; customer environment variable enumeration begins -- CONFIRMED — Vercel bulletin

Why is this same story repeated over and over here?

I get it, it's a big story ... but that doesn't mean it needs N different articles describing the same thing (where N > 1).

Funny how the headline tries to spin this as an env vars issue.

By far the biggest issue is being able to access the production environment of millions of customers from a Google Workspace. Only a handful of Vercel employees should be able to do that with 2FA if not 3FA.

To me the biggest (but not only) issue is that blindly connecting sensitive tools to 3rd party services has been normalized. Every time I hear the word "claw" I cringe...

Interesting - I wonder if this isn't a case of theft on a refresh token that was minted by a non-confidential 3LO flow w/PKCE. That would explain how a leaked refresh token could then be used to obtain access, but does the Vercel A/S not implement any refresh token reuse detection? i.e.: you see the same R/T more than once, you nuke the entire session b/c it's assumed the R/T was compromised.

> The CEO publicly attributed the attacker's unusual velocity to AI

Unusual velocity? Didn't the attacker have the oauth keys for months?

I'm building something that isn't necessarily more secure than vercel, but it is self hosted. I think in the future personal vps family clouds are going to be a lot more common because of these cloud-level attacks and costs.

What are these non-sensitive variables that could only be the NEXT_PUBLIC ones? else I haven’t seen any difference?

Or is it the UI sensitive that they ask you in CLI, that would be crazy. That means if you decide to not mark them as sensitive they don’t store encrypted ???

Environment variables are one of the most misused features of modern Unix. Storing secrets in them is insane, despite what the 12 factor people think.

Do any services use vercel?

I recently went to BreachForums and the space was filled with this

This article is solely overly wordy (probably ai) restatements of essentially just what vercel has publicly disclosed already

How did the Roblox cheat pass EDR?

I’m sure this has been said before but the new part of me is that the initial breach happened 22 months ago and has been sitting undetected that whole time. This really looks quite bad for vercel’s security posture.

If I were to interview someone and I see that they use Vercel, I'd immediately reject them.

Oauth is another flawed standard as I said before and this attack clearly shows that.

Security-by-obfuscation is ridiculed but I'm a firm believer that preventing yourself from getting owned when someone is able to type 3 letters `env` is a worthy layer of defense. Even if those same secrets are unencrypted somewhere else on the same system, at least make them spend a bunch of time crawling through files and such.

I hate environment variables. I hate them so so so much. I can’t think of a single time I would prefer an envvar to a config file.

They’re somewhat necessary when dealing with Docker. But I also hate Docker. So it’s not surprising when one bad design pattern leads to another.

I suppose maybe envvars make sense when dealing with secrets? I’m not sure. I don’t do any webdev. So not sure what’s least bad solution there.

[dead]

[dead]

[dead]

[dead]

[dead]