Live data from Hacker News

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

trendmicro.com

101–110 of 131 posts

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

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

Lifetime is the underlying issue.

For example, it is possible to create a vault lease for exactly one CI build and tie the lifetime of secrets the CI build needs to the lifetime of this build. Practically, this would mean that e.g. a token, some oauth client-id/client-secret or a username/password credential to publish an artifact is only valid while the build runs plus a few seconds. Once the build is done, it's invalidated and deleted, so exfiltration is close to meaningless.

There are two things to note about this though:

This means the secret management has to have access to powerful secrets, which are capable of generating other secrets. So technically we are just moving goal posts from one level to another. That is fine usually though - I have 5 vault clusters to secure, and 5 different CI builds every 10 minutes or so, or couple thousand application instances in prod. I can pay more attention to the vault clusters.

But this is also not easy to implement. It needs a vault cluster, dynamic PostgreSQL users take years to get right, we are discovering how applications can be terrible at handling short-lived certificates every month (and some even regress. Grafana seems to have with PostgreSQL client certs in v11/v12), we've found quite a few applications who never thought that certs with less than a year of lifetime even exists. Oh and if your application is a single-instance monolith, restarting to reload new short-lived DB-certs is also terrible.

Automated, aggressive secret management and revocation imo is a huge problem to many secret exfiltration attacks, but it is hard to do and a lot of software resists it very heavily on many layers.

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

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

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

#103

Earlier quoted context omitted.

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.

I'm not sure that's necessarily a "problem", though it is fundamental to secrets. We wouldn't say that it's a fundamental problem that doors on houses need a key--that's what the key is for--the problem is if the key isn't kept secure from unauthorized actors. Like, sure, you can go HAM here and use network proxy services to do secret decryption, and only talk from the app to those proxies via short-lived tokens; tha…

Speaking of fantansies...another approach would be holder binding: DPoP (RFC 9449) has been stable for a couple of years, AWS SigV4 does it too. The key holder proves control at call time, so a captured token without the key is useless.

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

#104

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…

I’ve said for a while now that there’s going to be a lot of bizarre security incidents in the news over the next few years.

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

#105
post #25

> 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

Blaming AI is gonna be the security breach equivalent to blaming ddos when your website breaks isn't it.

The idea of blaming something you can choice not to do is quite strange.

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

#106

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…

I see it the same way. Interesting times…

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

#107
post #85

Earlier quoted context omitted.

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

I prefer the devil and the 80s myself.

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

#108

Earlier quoted context omitted.

Blaming AI is gonna be the security breach equivalent to blaming ddos when your website breaks isn't it.

The idea of blaming something you can choice not to do is quite strange.

You can choose for attackers not to use AI?

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

#110

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

These are all made up and likely hallucinated.

It seems you're correct - the post has been modified.

> This entry was updated on April 21 to correct the incident timeline and scope characterization based on post-publication reporting from Context.ai's security bulletin.

> Key corrections: the initial compromise occurred in February 2026 (not June 2024), the initial access vector was Lumma Stealer malware (not an unknown mechanism), the dwell time was approximately two months (not 22 months),

Post reply on HN