39 comments

[ 5.5 ms ] story [ 48.7 ms ] thread
(comment deleted)
I recently went to BreachForums and the space was filled with this
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.
"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...

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.

(comment deleted)
(comment deleted)
(comment deleted)
> 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

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?
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.
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...
This article is solely overly wordy (probably ai) restatements of essentially just what vercel has publicly disclosed already
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).

> 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’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.
> The CEO publicly attributed the attacker's unusual velocity to AI

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

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.

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 ???

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

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