Vercel runtime must be able to access the values (so customer's apps can use them). But nobody else should ever be able to. This is the typical amateur hour security but on the other hand, who was naive enough to expect any better from vercel?

It's the new sophisticated nation state.

If they had SSO sign in to their admin panel (trusted device checks notwithstanding) the oauth access would be useless.

Vercel is understandably trying to shift all the blame on the third party but the fact their admin panel can be accessed with gmail/drive/whatever oauth scopes is irresponsible.

That's a low-leverage place to intervene. Whether or not the internal admin system was directly OAuth linked to Google, by the time the attacker was trying that, they already had a ton of sensitive/valuable info from the employee's Google Workspace account.

If you can only fix one thing (ideally you'd do both, but working in infosec has taught me that you can usually do one thing at most before the breach urgency political capital evaporates), fix the Google token scope/expiry, or fix the environment variable storage system.

I don't know why you are downvoted. The article is AI blogspam, it doesn't have any more factual information than eg https://www.darkreading.com/application-security/vercel-empl... and is full of empty LLMisms. It's depressing people are willing to read this.

> and is full of empty LLMisms

I dont have an llm-radar like you but I felt some anxiety reading through it. Cant explain why but the logic was not linear and this strained me as a reader. It didnt have the obvious llm-isms i see on youtube videos "not this but that". My natural instinct is to make sense of what I read, and if presented with a word-salad, it strains me. What are the empty LLMisms so my radar can be calibrated ? These are some giveaways I could spot.

> The timeline is genuinely absurd

> The timeline sequence description (Feb/March/April) is abstract and does not depict specifics reflecting human understanding.

I didn't notice till I saw this comment and now I'm also confident it's significantly AI written.

That article you linked to didn't mention that Context.ai, from where this mess originated, is a YCombinator company. Most probably its founders are on this very web-forum.

Has the article been edited since these comments? I see "It was a Y Combinator company" in the text.

Because a comment that just says it's AI generated provides no value to the readers. They could at least provide an alternative link like you did.

It does provide value in that I know I shouldn't read it. It's clearly LLM written after a few glances.

I was trying to look it up (basically https://developers.google.com/identity/protocols/oauth2/java... -- the consent screen shows the app name) but it now says "Error 401: invalid_client; The OAuth client was not found." so it was probably deleted by the oauth client owner.

It indeed was deleted as this URL shows: https://accounts.google.com/o/oauth2/v2/auth?client_id=11067...

Makes it even more relevant to have the actual app or vendor name - who’s to say they just removed it to save face and won’t add it later?

Why use AI generated pictures for the letters? Lot of the site wording is clearly AI too, but the pictures of final product are the most important aspect.

I'm genuinely asking, since it just makes the site look untrustworthy. The only thing balancing that are the real pictures of the peltier stamp process.

The site claims to be by cloudflare (didn't find a reverse link to confirm), so maybe they use their own little backdoor.

Associated blog post: https://blog.cloudflare.com/agent-readiness/

Anyone who relies on IP filtering for security deserves to have it broken. Change my mind.

I'll take that bait ;-)

IP filtering is a valuable factor for security. I know which IPs belong to my organisation and these can be a useful factor in allowing access.

I've written rules which say that access should only be allowed when the client has both password and MFA and comes from a known IP address. Why shouldn't I do that?

And there are systems which only support single-factor (password) authentication so I've configured IP filtering as a second factor. I'd love them to have more options but pragmatically this works.

Why are you (re-)implementing client security on provider end? If a client requires that only requests from a particular network are permitted... Peer in some way.

I do understand the value of blocking unwanted networks/addresses, but that's a bit different problem space.

Defense in depth is a thing but I agree that relying on it is not a good idea.

Defense in depth is not the point, zero trust networking is.

IP filtering + proper security is better than just having the security.

There's value in restricting access and reducing ones attack surface, if only to reduce noice in monitoring.

Actual curiosity, how would the new filtering be/is?

I've done a lot of IP filtering, it's what a lot of systems and services allow us to, so I'm curious what the IPv6 mechanism is

These people give the slopmachine credentials for their own github account?

I know I should not be surprised at this point, yet they keep reaching new lows.

Using your brain is so 2024, in 2026 you leave that to the AI

> Anthropic gave him a refund for the whole month that was underway, despite him being nearing the end of it

I sense an opportunity for free tokens.

Ideas for prompts that reliably trigger the age check?