Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

trendmicro.com

Post reply on HN
Print view View original

81–90 of 131 posts

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

#81

Post by [deleted] »

SoftTalker wrote: post #40
harikb wrote: post #35

Earlier quoted context omitted.

> with secrets possibly baked into source please don't suggest this. The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM (with machine level identify managed by the parent platform) This is how Google Secrets or AWS Vaults work.

This is just another layer of indirection (which isn't bad; it adds to the difficulty of executing a breach). The fundamental problem with encrypted secrets is that at some point you need to access and decrypt them.

[deleted]

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

#82

Post by whh »

chatmasta wrote: post #74
harikb wrote: post #35

Earlier quoted context omitted.

> with secrets possibly baked into source please don't suggest this. The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM (with machine level identify managed by the parent platform) This is how Google Secrets or AWS Vaults work.

Next.js renders configuration that’s shared by client and server into a JSON blob in the HTML page. These config variables often come from environment variables. It’s a very common mistake for people to not realize this, and accidentally put what should be a server-only secret into this config. I’ve seen API secrets in HTML source code because of this. The client app doesn’t even use it, but it’s part of the next con…

That's essentially what NEXT_PUBLIC_ is for... but serializing process.env is a new one for me.

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

#83

Post by socalgal2 »

chatmasta wrote: post #74
harikb wrote: post #35

Earlier quoted context omitted.

> with secrets possibly baked into source please don't suggest this. The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM (with machine level identify managed by the parent platform) This is how Google Secrets or AWS Vaults work.

Next.js renders configuration that’s shared by client and server into a JSON blob in the HTML page. These config variables often come from environment variables. It’s a very common mistake for people to not realize this, and accidentally put what should be a server-only secret into this config. I’ve seen API secrets in HTML source code because of this. The client app doesn’t even use it, but it’s part of the next con…

IIRC, react had this issue so they required env vars seen in react to be prefixed by REACT_ The hope being that SECRET is not prefixed and so is not available. Of course it requires you to know why they are prefixed and not make REACT_SECRET

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

#84

Post by raw_anon_1111 »

throwaway27448 wrote: post #5

Do any services use vercel?

I used v0 for a vibe coded internal admin app.

*BUT* I downloaded the source code from Vercel’s site, built and deployed in a Docker container (I never download random npm packages to my local computer), deployed the Docker container to Lambda (choose your Docker deployment platform. They are a dime a dozen), had a tightly scoped IAM role attached to the Lambda and my secrets were in Secret Manager.

My deployment also had a placeholder for the secrets when it was deployed and they were never in my repo and purposefully had to be manually configured.

I would never trust something like Vercel for hosting. I’m not saying go all in on a major cloud provider. Get your own cheap VPS if that’s all you need and take responsibility for your own security posture the best you can.

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

#85

Post by mday27 »

12_throw_away wrote: post #63
thundergolfer wrote: post #51

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

Seems like AI is really disrupting the markets for nonsensical excuses the media will repeat uncritically!

It's like we're back in 2009 with "did social media cause this?"

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

#86

Post by kyle-rb »

_pdp_ wrote: post #29
tom1337 wrote: post #27

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 acce…

Once you have a session token, which is what you get after you complete the oauth dance, you can issue requests to the API. It is simple as that. The minted token had permission to access the victim's inbox, most likely, which the attacker leveraged to read email and obtain one-time passwords, magic links and other forms of juicy information.

I guess what's unusual is that the scope includes inbox access.

IMO it's probably a bad idea to have an LLM/agent managing your email inbox. Even if it's readonly and the LLM behaves perfectly, supply chain attacks have an especially large blast radius (even more so if it's your work email).

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

#87

Post by tosser12344321 »

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

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

#88

Post by chatmasta »

whh wrote: post #82
chatmasta wrote: post #74

Earlier quoted context omitted.

Next.js renders configuration that’s shared by client and server into a JSON blob in the HTML page. These config variables often come from environment variables. It’s a very common mistake for people to not realize this, and accidentally put what should be a server-only secret into this config. I’ve seen API secrets in HTML source code because of this. The client app doesn’t even use it, but it’s part of the next con…

That's essentially what NEXT_PUBLIC_ is for... but serializing process.env is a new one for me.

They don’t serialize process.env, but devs will take config values from environment variables. Obviously you’re not supposed to do this but it’s a footgun.

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

#89

Post by oasisbob »

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

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

#90

Post by oasisbob »

saadn92 wrote: post #11

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-part…

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

That statement in the report really confuses me; feels illogical and LLM generated.

An old deployment using an older env var doesn't do anything to control whether or not the credential is still valid. This is a footgun which affects availability, not confidentiality like implied.

Another section in the report is confusing, "Environment variable enumeration (Stage 4)". The described mechanics of env var access are bizarre to me -

> Pay particular attention to any environment variable access originating from user accounts rather than service accounts, or from accounts that do not normally interact with the projects being accessed.

Are people really reading credentials out of vercel env vars for use in other systems?

Post reply on HN