Live data from Hacker News

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

trendmicro.com

1–10 of 131 posts

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

#1
Vercel April 2026 security incident - https://news.ycombinator.com/item?id=47824463 - April 2026 (485 comments)

A Roblox cheat and one AI tool brought down Vercel's platform - https://news.ycombinator.com/item?id=47844431 - April 2026 (145 comments)

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

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

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

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

#6
post #4

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.

It's ridiculed because its no protection on its own when an attacker is motivated. Its fine to add as an additional layer though if you want to make your space mildly custom to protect against broader attacks.

I don't see how its necessarily relevant to this attack though. These guys were storing creds in clear and assuming actors within their network were "safe", weren't they?

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

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

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

#8
post #4

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.

It's ridiculed because its no protection on its own when an attacker is motivated. Its fine to add as an additional layer though if you want to make your space mildly custom to protect against broader attacks. I don't see how its necessarily relevant to this attack though. These guys were storing creds in clear and assuming actors within their network were "safe", weren't they?

TFA cites "env var enumeration", likely implying someone got somewhere they shouldn't and typed 3 characters, as the critical attack that led to customers getting compromised.

My point is sensitive secrets should literally never be exported into the process environment, they should be pulled directly into application memory from a file or secrets manager.

It would still be a bad compromise either way, but you have a fighting chance of limiting the blast radius if you aren't serving secrets to attackers on an env platter, which could be the first three characters they type once establishing access.

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

#9

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

As someone trying to think about OAuth apps at our SaaS, it certainly is very hard.

Do any marketplaces have a good approach here? I know Cloudflare, after their similar Salesloft issue, has proposed proxying all 3rd party OAuth and API traffic through them. But that feels a little bit like trading one threat vector for another.

Other than standard good practices like narrow scopes, shorter expirations, maybe OAuth Client secret rotation, etc, I'm not sure what else can be done. Maybe allowlisting IP addresses that the requests associated with a given client can come from?

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

#10
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...
Post reply on HN