61–70 of 131 posts
Earlier quoted context omitted.
I mean the admin account had visibility of clients env vars, thats maybe not really great in the first place.
you'd think. but this is a js dev world. nextjs app bake all env vars on the client side code!! it's all public, unless you prefix the name with private_ or something.
You preface with PUBLIC_ to expose them in client side code.
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…
yeah not redeploying on credential changes seems like a design flaw. Render redeploys on env var changes, for instance.
> 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.
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.
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.
HSMs & similar can at least time-limit access to secrets to the period where an attacker can make requests to the HSM.
The service that encrypts the data should be the ONLY service that holds the private key to decrypt, and therefore the only service that can process the decrypted data.
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 ???
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 ???
Earlier quoted context omitted.
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 C…
This was probably partly a Google refresh token theft (given the length of the access). No inside info, just looking at how the attack occurred. OAuth 2.1[0] (an RFC that has been around longer than I've been at my employer) recommends some protections around refresh tokens, either making them sender constrained (tied to the client application by public/private key cryptography) or one-time use with revocation if it…
That's standard in oidc I believe
Earlier quoted context omitted.
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…
The following is based on my interpretation of information that's been made public: A Vercel user had their Google Workspace compromised. The attacker used the compromised workspace to connect to Vercel, via Vercel's Google sign-on option. The attacker, properly logged into the Vercel console as an employee of that company, looked at the company's projects' settings and peeked at the environment variables section, wh…
Earlier quoted context omitted.
Usually rotating a credential means that you invalidate the previous one. Never heard of rotating credentials that would only create new ones and keep the old ones active.
But then every rotation would break production, wouldn't it ?
Then you remove the old credential from the endpoint.