back
492 comments
When 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 interviews about the single responsibility principle, meanwhile the industry's business model is to undermine the entirety of web standards and consolidate the web stack into a CLI.

Coming from a company that makes infrastructure out of a view layer / vDOM library - I think anyone relying on Vercel has only themselves to blame.
You have no idea how indifferent security officers can be-even when you point out critical issues. The other day, we flagged that a customer’s database had users with excessive privileges. Their only question: “Can this be exploited from the outside?”

No, but most breaches today come from compromised internal accounts that are then used to break everything.

JavaScript living only as a built artifact in an s3 bucket makes for a much simpler life.
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.
Polite reminder as to why Domain Driven Design is super-important. It makes more sense to spend 80% on DDD initially and then only 20% on the code (80-20 rule) vs the other way round. Or you will end up in a clusterfuck like this.
GitHub looking awful quiet in the corner on the room there
three critical vulns in 12 months is a pattern not a coincidence. the SRP point is sharp - we interview engineers on isolation principles then build platforms that are the opposite of that.
Claude Code defaulting to a certain set of recommended providers[0] and frameworks is making the web more homogenous and that lack of diversity is increasing the blast radius of incidents

[0] https://amplifying.ai/research/claude-code-picks/report

It's interesting how many of the low-effort vibecoded projects I see posted on reddit are on vercel. It's basically the default.
They just added more details:

> Indicators of compromise (IOCs)

> Our investigation has revealed that the incident originated from a third-party AI tool whose Google Workspace OAuth app was the subject of a broader compromise, potentially affecting hundreds of its users across many organizations.

> We are publishing the following IOC to support the wider community in the investigation and vetting of potential malicious activity in their environments. We recommend that Google Workspace Administrators and Google Account owners check for usage of this app immediately.

> OAuth App: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

https://vercel.com/kb/bulletin/vercel-april-2026-security-in...

I've been part of a response team on a security incident and I really feel for them. However, this initial communication is terrible.

Something happened, we won't say what, but it was severe enough to notify law enforcement. What floors me is the only actionable advice is to "review environment variables". What should a customer even do with that advice? Make sure the variable are still there? How would you know if any of them were exposed or leaked?

The advice should be to IMMEDIATELY rotate all passwords, access tokens, and any sensitive information shared with Vercel. And then begin to audit access logs, customer data, etc, for unusual activity.

The only reason to dramatically overpay for the hosting resources they provide is because you expect them to expertly manage security and stability.

I know there is a huge fog of uncertainly in the early stages of an incident, but it spooks me how intentionally vague they seem to be here about what happened and who has been impacted.

There are 3 main questions here:

1) Vercel rolled out sensitive secrets on February 1, 2024, why were not all existing env vars transitioned to sensitive type? Why was there any assumption that any secret added as env var before that date was still OK to be left as "non-sensitive".

2) How was actually the Google workspace account was compromised? If context.ai was the originating issue, what actually led to the takeover? Were there too many access privileges given to the Google Workspace token context.ai had, or was there actually a workstation takeover here?

3) And finally why the hack a compromised Google Workspace account lead to someone having access to bunch of customer projects? Were is the connection? I don't get this..

> Vercel did not specify which of its systems were compromised

I’m no security engineer, but this is flatly unacceptable, right? This feels like Vercel is covering its own ass in favor of helping its customers understand the impact of this incident.

I'm on a macbook pro, Google Chrome 147.0.7727.56.

Clicking the Vercel logo at the top left of the page hard crashes my Chrome app. Like, immediate crash.

What an interesting bug.

They just added more details:

> Indicators of compromise (IOCs)

> Our investigation has revealed that the incident originated from a third-party AI tool whose Google Workspace OAuth app was the subject of a broader compromise, potentially affecting hundreds of its users across many organizations.

> We are publishing the following IOC to support the wider community in the investigation and vetting of potential malicious activity in their environments. We recommend that Google Workspace Administrators and Google Account owners check for usage of this app immediately.

> OAuth App: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

https://vercel.com/kb/bulletin/vercel-april-2026-security-in...

Related: https://news.ycombinator.com/item?id=47824426

https://x.com/theo/status/2045862972342313374

> I have reason to believe this is credible.

https://x.com/theo/status/2045870216555499636

> Env vars marked as sensitive are safe. Ones NOT marked as sensitive should be rolled out of precaution

https://x.com/theo/status/2045871215705747965

> Everything I know about this hack suggests it could happen to any host

https://x.com/DiffeKey/status/2045813085408051670

> Vercel has reportedly been breached by ShinyHunters.

Am I reading this[1] correctly that they basically had that "compromised OAuth token" for a month now and it was only detected now when the attackers posted about it in a forum?

[1] https://context.ai/security-update

The lack of details makes me wonder how large this "subset" of users really is
Is this one of those situations where _a lot_ of customers are affected and the “subset” are just the bigger ones they can’t afford to lose?
Incidents like this are a good reminder of how concentrated our single points of failure have become in the modern web ecosystem. I appreciate the transparency in their disclosure so far, but it definitely makes you re-evaluate the risk profile of leaning entirely on fully managed PaaS solutions.
This is why you pay a real provider for serious business needs, not an AWS reseller. Next.js is a fundamentally insecure framework, as server components are an anti-pattern full of magic leading to stuff like the below. Given their standards for framework security, it's not hard to believe their business' control plane is just as insecure (and probably built using the same insecure framework).

Next.js is the new PHP, but worse, since unlike PHP you don't really know what's server side and what's client side anymore. It's all just commingled and handled magically.

https://aws.amazon.com/security/security-bulletins/rss/aws-2...

A "limited subset of customers" could be 99% of them and the phrase would still be technically true.
ha, if anyone is interested, I wrote about how I migrated away from Vercel. good timing: https://saadnaveed.com/writing/vercel-to-hetzner/
Vercel, a deployment shell script turned billion dollar company, turned global liability. A story older than time.
This announcement in its current form is quite useless and not actionable. As least people won’t be able to say “why didn’t you say something sooner?” They said _something_
The original link posted in the post has almost same content: https://vercel.com/kb/bulletin/vercel-april-2026-security-in...
Neon, the Vercel recommended database storage integration, doesn't use the sensitive option for the environment variables it manages including the database connection string/password and need to be rotated then deleted and manually set up as sensitive.
Use VPS, nowadays with the help of AI it's a lot easier to set everything up, you don't need Versel at all. And of course way cheaper
Wow, maybe Cloudflare can help them secure their systems? I hear they have a pretty good WAF.
So, the Vercel post says a number of customers were impacted, but not everyone, and they will contact the people that were impacted. I wasn't contacted so does that mean I'm safe?
Context AI published a statement https://context.ai/security-update

> Last month, we identified and stopped a security incident involving unauthorized access to our AWS environment.

> Today, based on information provided by Vercel and some additional internal investigation, we learned that, during the incident last month, the unauthorized actor also likely compromised OAuth tokens for some of our consumer users.

What is the rationale for using vercel ? I'm getting a lot of value out of cloudflare with the $5/month plan lately but my bare metal box with triple digit ram has seen zero downtime since 2015.
The real story isn't Vercel. It's that a Context.ai employee got infostealer'd in February and four months later that single compromise propagated through an 'Allow All' Google Workspace OAuth grant into Vercel's env vars. This is less a Vercel incident and more the chronic OAuth-supply-chain problem finally surfacing somewhere visible.
While everyone is revoking OAuth apps, rotating API keys, and deleting Vercel accounts, this is a good reminder that the scary part is how short the path was from OAuth token to employee account to internal systems to customer secrets.

Many folks here likely have some stack that looks like: Google Workspace, GitHub, Vercel/Railway/Render/etc. where env vars or secrets are hosted. These are all loosely coupled but transitively trusted.

So compromising any one of them becomes a threat vector. In other words, if System A trusts System B, and System B trusts System C, then System A trusts System C. This is also why OpenClaw is frightening from a security perspective.

Also, this is a good reminder to run audits. Run `npm audit` on a typical Next.js project and you’ll probably see DoS vulnerabilities, ReDoS issues, Prototype pollution, code injection paths, handlebars etc. I'm sure you'll find something unexpected if you don't have routine code hygiene checks.

An email from Vercel came to my company at 10:47am UTC. It contained little information, and said:

> At this time, we do not have reason to believe that your Vercel credentials or personal data have been compromised.

Which is not very reassuring without actual information, since presumably they would have said the same thing on Saturday, if asked.

Why does anyone running a third party tool have access to all of their clients’ accounts? I can’t imagine something this stupid happening with a real service provider.

I see Vercel is hosted on AWS? Are they hosting every one on a single AWS account with no tenant isolating? Something this dumb could never happen on a real AWS account. Yes I know the internal controls that AWS has (former employee).

Anyone who is hosting a real business on Vercel should have known better.

I have used v0 to build a few admin sites. But I downloaded the artifacts, put in a Docker container and hosted everything in Lambda myself where I controlled the tenant isolation via separate AWS accounts, secrets in Secret Manager and tightly scoped IAM roles, etc.

We run on Vercel and I wonder if / how long before we're alerted about a leak. Quick look online suggests environment variables marked as sensitive are ok, but to which extent I wonder.
We proactively rotated keys. Even if you haven’t received an official email, expect customers to inquire about this tomorrow morning.
This is why I moved my video streaming app (strimoza.com) to signed URLs with short expiry times for every single request. Extra complexity but at least if something leaks, the damage is contained. Curious how many people actually audit their CDN token policies before an incident forces them to.
Porter also had a breach recently. I assume it is as tightly scoped as they say to not have publicized it.
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.
Is the calculus breaking for these cloud providers? They are vibe coding at unsustainable speeds and shit is just breaking left and right.

Has anyone made the move to self hosting on their own servers again?

> incident response provider

So they use third-party for incident management? They are de-risking by spending more, which is a loose-loose for the customers.

Time to ipo
Finally got an email from Vercel saying that my account probably isn't compromised.

7:57 AM Monday, April 20, 2026 Coordinated Universal Time (UTC)