Vercel runs the infrastructure that most modern SaaS companies deploy on. Next.js is theirs. Their customer list reads like a YC directory. If you have shipped a product in the last three years, you have probably deployed on Vercel or worked with a company that has.
Last weekend, they disclosed a breach.
The attacker did not find a zero-day in Vercel’s code. Did not breach AWS or Cloudflare. Did not run a months-long campaign against Vercel’s infrastructure directly.
A Vercel employee downloaded a small AI productivity tool, connected it to their work Google account, and clicked Allow All on the permissions prompt. That was the entire attack surface the attacker needed.
What actually happened, step by step
Total time from a game script download to production credentials for sale: roughly two months. Zero technical sophistication required against Vercel directly. Just patience and a valid OAuth token that nobody had revoked.
The thing that made the whole chain possible
Nobody at Vercel had visibility into which third-party tools their employees had connected to their corporate Google Workspace.
That is not a Vercel-specific failure. It is the default state at most companies.
Employees connect tools constantly. A meeting notes app. An AI writing assistant. A productivity tool someone on the growth team found useful. Some get approved by IT. Most do not. The tool gets used for a sprint, the employee moves on, the OAuth permission persists indefinitely with nobody watching it.
Vercel confirmed the incident originated from a small third-party AI tool whose Google Workspace OAuth app was subject to a broader compromise, potentially affecting hundreds of users across many organizations. Most of them probably do not know yet.
What this looks like at your company right now
If you are running a 20 to 100 person startup, you probably have somewhere between 15 and 40 third-party tools connected to your Google Workspace or Microsoft 365 accounts right now. Some were approved by your CTO. Most were connected by individual employees who needed them for a project and clicked through the OAuth prompt without reading what they were granting.
Some of those tools are well-resourced companies with mature security programs. Some are two-person startups with one engineer managing AWS on a shared laptop.
You have no way of knowing which is which. And you have probably not reviewed which OAuth applications have access to your corporate accounts in the last 12 months.
This is not a criticism. It is how software adoption works at fast-moving companies. A tool is useful, someone connects it, it stays connected. The problem is that “stays connected” means “maintains access to your email, your calendar, your files, and in some configurations your ability to act as your users inside your corporate environment.”
Vercel’s environment variables marked as sensitive are stored encrypted. There is no evidence those were accessed. The ones that were not marked sensitive were the problem. The company that invented edge deployment for the modern web did not have a policy requiring all production credentials to be marked sensitive. Not because they are careless. Because at the speed modern companies operate, the assumption is that the tools employees use are safe, and that the tools those tools use are safe too.
That assumption is the vulnerability.
The three controls that break this chain
Every OAuth application connected to corporate Google Workspace accounts, listed, categorised by permission scope, flagged when access is unusually broad. The specific OAuth client ID that enabled this breach is now public. A company running continuous monitoring would have found it and revoked it before the attacker used it.
The Lumma Stealer infection happened on a Context.ai employee’s machine. Endpoint detection running on that machine would have caught the credential harvesting behaviour before a single token was compromised. The entire chain starts and ends at an unprotected endpoint.
Vercel has now shipped a product update making sensitive the default setting for environment variable creation. That lesson cost them a breach. It does not have to cost you one.
None of these require a dedicated security team. None take months to implement. The hard part is not the controls themselves. It is knowing you need them before the incident report lands.
What to do right now if you use Vercel
-
✓
Rotate all environment variables that were not marked sensitive and treat them as compromised -
✓
Review your activity log for unexpected deployments -
✓
Enable 2FA if you have not already -
!
Go to your Google Workspace Admin Console and check for this client ID:110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. If you find it, revoke access immediately. -
!
Then look at everything else on that list. The number of apps with broad access to your corporate environment will surprise you.
The bigger pattern
Supply chain attacks keep working because of one assumption: that the perimeter is your code, your servers, your access controls.
The real perimeter extends to every tool, every vendor, every OAuth connection any employee has ever granted. Black Kite’s 2026 Third-Party Breach Report found that each vendor breach now creates an average of 5.28 downstream victims, with an average of 117 days from breach to public disclosure. Meaning companies are operating under active compromise for nearly four months before they know it.
Vercel is the headline. The other companies on that Context.ai OAuth token list are not headlines yet.
The question for any founder or CTO reading this is not whether this could happen to you. It is whether it is happening right now and you do not know yet. That question has a different answer depending on whether you have continuous monitoring across your environment or not.
Osto runs the three layers this chain moved through.
Endpoint protection that catches credential-harvesting malware before it compromises tokens. WAF coverage on the application layer those stolen credentials were designed to reach. And continuous third-party access monitoring so an OAuth connection granted by an employee on a Tuesday does not become a breach you find out about four months later.
If you want to see what is currently connected to your environment with broad permissions, we can show you in an afternoon.