Not very familiar with Vercel. Discovered them only recently when a business my brother is a customer of fell victim of a phishing attack. The "Login to Microsoft" page hosted on Vercel was still online many days later when I heard of the case.
Vercel April 2026 security incident
381–390 of 540 posts
Re: Vercel April 2026 security incident
#382[flagged]
good point, we think of these OAuth logins as so safe and yet they may be the exact opposite because it's more like logging in with your master password. I think these oauth providers like Microsoft and Google need to start mandating 2FA for every company login, it's just too dangerous otherwise.
Re: Vercel April 2026 security incident
#383Earlier quoted context omitted.
Yeah definitely no difference between GNU coreutils and some vibe coded AI tool released last month that wants full oAuth permissions.
I’m not joking, but weirdly enough, that’s what most AI arguments boil down to. Show me what the difference is while I pull up the endless CVE list of which ever coreutils package you had in mind. It’s a frustrating argument because you know that authors of coreutils-like packages had intentionality in their work, while an LLM has no such thing. Yet at the end, security vulnerabilities are abundant in both. The AI ma…
Now I'd genuinely like to know whether "yes" had a CVE assigned, not sure how to search for it though...
Re: Vercel April 2026 security incident
#384Earlier quoted context omitted.
It's interesting how many of the low-effort vibecoded projects I see posted on reddit are on vercel. It's basically the default.
Reddit vibecoded LLM posts are kind of fascinating for how homogenous they are. The number of vibe coded half-finished projects posted to common subreddits daily is crazy high. It’s interesting how they all use LLMs to write their Reddit posts, too. Some of them could have drawn in some people if they took 5 minutes to type an announcement post in their own words, but they all have the same LLM style announcement pos…
[deleted]
Re: Vercel April 2026 security incident
#385[flagged]
I'm not super savvy with OAuth, but shouldn't scopes prevent issues like this?
Re: Vercel April 2026 security incident
#386Earlier quoted context omitted.
> It’s about as insecure as having one Apache Server serving multiple customer’s accounts. You really have no clue what you’re talking about don’t you? Were you a sales guy at AWS or something?
Well, I know that you have never heard of someone using a third party SaaS product at any major cloud provider compromising all of their customers accounts. Are you really defending Vercel as a hosting platform that anyone should take seriously?
How is any of that a defense of Vercel? If you understood how any of this works you’d know that it isn’t. Vercel is a manifestation of what’s wrong with web development, yet it has nothing to do with “creating an AWS account per user account” nor “running a reverse proxy process per user account”.
Re: Vercel April 2026 security incident
#387When one OAuth token can compromise dev tools, CI pipeline, secrets and deployment simultaneously, something architectural has gone wrong. Vercel have had React2Shell (CVSS 10), the middleware bypass (CVSS 9.1), and now this, all within 12 months. At what point do we start asking questions about the concentration of trust in the web ecosystem? It's funny that at the engineering level we are continuously grilled in in…
The whole hiring system needs to be eradicated. You get grilled by incompetents, who ask one question, never ask back when you provide something that is debatable, they give zero feedback and then you see what kind of errors these "elitist" engineers make. Burn it to the ground.
Re: Vercel April 2026 security incident
#388[flagged]
I remember implementing OAuth2 for my platform months ago and I was using the username from the provider's platform as the username within my own platform... But this is a big problem because what if a different person creates an account with the same username on a different platform? They could authenticate themselves onto my platform using that other provider to hijack the first person's account!
Thankfully I patched this issue just before it became a viable exploit because the two platforms I was supporting at the time had different username conventions; Google used email addresses with an @ symbol and GitHub used plain usernames; this naturally prevented the possibility of username hijacking. I discovered this issue as I was upgrading my platform to support universal OAuth; it would have been a major flaw had I not identified this. This sounds similar to the Vercel issue.
Anyway my fix was to append a unique hash based on the username and platform combination to the end of the username on my platform.
Re: Vercel April 2026 security incident
#389[flagged]
How does that work, when you add an OAuth app, the resulting tokens are specific to that app having a certain set of permissions?
It's not a new attack vector as in giving too many scopes (beyond the usual "get personal details").
I am curious how this external OAuth app managed to move through the systems laterally.
Re: Vercel April 2026 security incident
#390[flagged]
I remember implementing OAuth2 for my platform months ago and I was using the username from the provider's platform as the username within my own platform... But this is a big problem because what if a different person creates an account with the same username on a different platform? They could authenticate themselves onto my platform using that other provider to hijack the first person's account! Thankfully I patch…
You should use the subject identifiers, not the usernames. You store a mapping of provider & subject to internal users yourself.
But this has been a problem in the past where people would hijack the email and create a new Google account to sign in with Google with.
Similarly, when someone deletes their account with a provider, someone else can re-register it and your hash will end up the same. The subject identifiers should be unique according to the spec.