Vercel Got Pwned Through an AI Tool Nobody Audited

Vercel Confirmed a Breach. The Entry Point Was Not What You Would Expect.

On April 19, 2026, Vercel published a security bulletin that made a lot of frontend engineers very uncomfortable very quickly. The company confirmed unauthorised access to certain internal systems. Not a theoretical vulnerability disclosure. Not a "we found and patched it before anything happened" post. An actual breach, with actual data exposure, affecting actual customers.

The immediate reaction across Twitter, LinkedIn, and various engineering Slacks was what you would expect - a mix of panic, scepticism, and "I told you so" from the self-hosted crowd. But the real story was not the breach itself. Breaches happen. Cloud providers get compromised. That is the world we operate in.

The real story was how the attackers got in.

They did not find a zero-day in Vercel's deployment infrastructure. They did not brute-force an admin panel. They did not exploit some ancient unpatched dependency buried in the platform's stack. Instead, they compromised a third-party AI tool called Context.ai that a single Vercel employee was using. From there, they pivoted into the employee's Google Workspace account. And from there, they walked into Vercel's internal environments like they had a badge.

One AI tool. One employee. The entire platform's security posture, bypassed.

From Context.ai to Full Internal Access in Three Steps

Let me walk through the attack chain, because understanding it is the difference between thinking "this could never happen to us" and realising it probably already could.

Step 1: Compromise Context.ai

Context.ai is one of those AI productivity tools that have exploded in popularity over the past year. It integrates with your workspace - email, documents, calendars - to provide AI-powered insights and assistance. To do that, it needs OAuth access to your Google Workspace. Broad OAuth access. The kind that lets it read your emails, access your drive, and interact with your workspace on your behalf.

The attackers compromised Context.ai first. The specifics of how they got into Context.ai have not been fully disclosed, but the outcome was clear: they gained the ability to leverage Context.ai's OAuth connections to access the Google Workspace accounts of Context.ai users.

Step 2: Pivot to a Vercel Employee's Google Workspace

At least one Vercel employee was using Context.ai. Through the compromised OAuth connection, the attackers took over that employee's Google Workspace account. This is the critical link in the chain - a personal tool choice by one employee became the entry vector for the entire organisation.

Step 3: Access Vercel Internal Environments

With control of a Vercel employee's Google Workspace, the attackers gained access to internal Vercel environments. Vercel described them as "highly sophisticated based on their operational velocity and detailed understanding of Vercel's systems." They knew exactly where to look and moved fast.

// The path from AI tool to platform compromise

Context.ai compromised
    ↓  (OAuth token abuse)
Employee Google Workspace taken over
    ↓  (internal SSO / workspace access)
Vercel internal environments accessed
    ↓  (environment variable exfiltration)
Customer API keys, tokens, credentials exposed

// Compromised OAuth App ID:
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj
    .apps.googleusercontent.com

Vercel published the compromised OAuth application identifier so organisations could check their own Google Workspace admin consoles. If that OAuth app ID appears in your tenant's authorised applications, you have a problem that extends well beyond Vercel.

Environment Variables Were the Prize

Here is where it gets directly relevant to every team running production workloads on Vercel.

The attackers accessed environment variables that were not marked as "sensitive" in Vercel's system. If you have ever deployed anything on Vercel, you know the environment variables panel. You put your API keys there, your database connection strings, your third-party service tokens, your webhook secrets. It is convenient. It is also, apparently, the thing that got exposed.

Vercel makes a distinction between regular environment variables and ones marked as "sensitive." Sensitive variables are stored encrypted and cannot be read back through the dashboard or API once set. Regular environment variables - the ones most teams use for most things - are stored in a way that made them accessible to the attackers.

The practical impact varies by team. For a static marketing site, the exposure might be limited to a CMS API key with read-only access. Annoying, but not catastrophic. For a fintech startup with database credentials, payment processor API keys, and JWT signing secrets in their Vercel environment variables? That is a different conversation entirely.

ShinyHunters, $2 Million, and a Lot of Unverified Claims

Almost simultaneously with Vercel's disclosure, a listing appeared on BreachForums - the cybercrime marketplace that has become the default storefront for stolen data. The post, attributed to the "ShinyHunters" moniker, claimed to be selling Vercel data for $2 million. The alleged haul included access keys, source code, database information, and API keys linked to internal deployments.

Here is the interesting bit: when security researchers reached out to the actual ShinyHunters group, they denied involvement. This suggests either a copycat actor using an established name for credibility, or loosely affiliated individuals trading on the ShinyHunters brand. Either way, the data listing exists, and the claims have not been debunked.

Whether the asking price is realistic is another question. $2 million for platform-level access keys and source code from a company valued in the billions is not outlandish. But the cybercrime marketplace is full of exaggerated claims, repackaged data from older breaches, and outright fabrication. The prudent move - and the one Vercel is recommending - is to assume the worst and act accordingly.

Vercel has engaged Mandiant (Google's incident response arm) along with additional cybersecurity firms and law enforcement. They have stated they are "continuing to investigate what data was exfiltrated." That phrasing is worth noting - they are not saying "we have confirmed the full scope." They are still figuring out how bad it is.

Web3 Teams Are Scrambling - and They Should Be

If there is one category of Vercel user that should be losing sleep over this, it is crypto and Web3 teams. And they are.

A huge number of DeFi frontends, NFT platforms, and crypto trading interfaces run on Vercel. It makes sense - Vercel's edge network is fast, the developer experience is excellent, and Next.js (built by Vercel) is the framework of choice for most Web3 frontends. The problem is that these frontends often store credentials in Vercel environment variables that connect directly to blockchain infrastructure, wallet services, and backend APIs controlling real money.

Orca, the Solana-based decentralised exchange, publicly confirmed they rotated all deployment credentials as a precaution. Their on-chain protocol and user funds were not affected - but the fact that a major DEX had to issue a public statement about a frontend hosting provider's breach tells you everything about how the blast radius of this incident extends.

This breach hit during what CoinDesk called "an exceptionally difficult month for crypto security" - alongside the $292 million Kelp DAO exploit and roughly a dozen other protocol attacks. The timing is coincidental, but it compounds the anxiety. When your hosting provider, your smart contracts, and your bridge protocols are all getting hit in the same month, the "move fast and break things" ethos starts to feel less like a philosophy and more like a prophecy.

AI Tools Are the New Shadow IT - and Nobody Is Auditing Them

Step back from the Vercel-specific details for a moment and look at the structural problem this breach exposes. A single employee used a third-party AI tool. That tool had OAuth access to their Google Workspace. When the tool got compromised, the attacker inherited all of those OAuth permissions.

This is not a Vercel problem. This is an everyone problem.

Think about your own organisation. How many AI tools have your engineers authorised via Google OAuth or GitHub OAuth in the past twelve months? Cursor, Copilot, various AI code review tools, AI meeting note-takers, AI email assistants, AI document summarisers. Each one of those is a potential Context.ai - a third-party service with broad access to your internal systems that was never reviewed by your security team.

The old shadow IT problem was employees installing Dropbox or using personal Gmail for work. The new shadow IT problem is employees granting AI tools OAuth access to corporate systems. The difference is that the new tools often request - and receive - far broader permissions than a file sync service ever did. An AI assistant that can read your email, access your calendar, browse your documents, and act on your behalf is not a productivity tool. It is a fully-privileged proxy that happens to be controlled by a startup you have never audited.

Security teams that are not actively inventorying and reviewing AI tool OAuth grants are operating blind. And based on the conversations I have had since this breach dropped, most security teams are not doing this. Not because they do not care, but because the volume of AI tools being adopted across engineering, product, and leadership teams has outpaced any governance framework.

Your Env Vars Are Not Secrets (Unless You Treat Them Like Secrets)

This breach also highlights a fundamental misunderstanding that pervades frontend engineering: the assumption that environment variables are inherently secure. They are not. They never were. An environment variable is just a key-value pair injected at build time or runtime. Its security depends entirely on how the platform stores, transmits, and access-controls it.

Vercel's "sensitive" flag exists precisely because regular environment variables are not stored with the same protections. But how many tutorials, blog posts, and Stack Overflow answers have you read that say "just put your API key in an environment variable" without any qualification about sensitivity levels, access controls, or rotation policies?

// What every tutorial tells you:
NEXT_PUBLIC_API_KEY=pk_live_abc123     // "just add it to env vars"
DATABASE_URL=your-database-connection-string-here  // "Vercel handles it"
STRIPE_SECRET_KEY=sk_live_xyz789     // "it's server-side only"
JWT_SIGNING_SECRET=supersecret       // "nobody can see this"

// What you should actually be doing:
// 1. Mark ALL secret values as "sensitive" in Vercel
// 2. Use a dedicated secrets manager (Vault, AWS SM, etc.)
// 3. Rotate credentials on a regular cadence
// 4. Audit which env vars are truly needed at build time
// 5. Never store long-lived credentials if short-lived tokens work

The "sensitive" flag in Vercel is a write-once mechanism - once set, the value cannot be read back through the UI or API. It can only be used by the deployment runtime. This is meaningfully more secure than the default, but it comes with friction: you cannot copy-paste the value later, you cannot easily rotate it without going through a specific flow, and it is not the default. So most teams never use it.

Convenience won. Security lost. As it almost always does, until something like this happens.

The Immediate Action Checklist

If you are running production workloads on Vercel, here is what you should be doing right now. Not next sprint. Not "when we get to it." Now.

1. Audit your environment variables. Log into every Vercel project your team owns. Identify every environment variable that contains a secret - API keys, database credentials, tokens, signing keys. If it is not marked as "sensitive," assume it has been exposed.
2. Rotate everything that matters. Every API key, every database password, every JWT secret, every webhook signing key that was stored as a non-sensitive environment variable needs to be rotated. Yes, all of them. Yes, it is a pain. Do it anyway.
3. Enable the sensitive flag going forward. For every secret you rotate, set the new value with the "sensitive" flag enabled. Accept the minor inconvenience of not being able to read it back.
4. Check the OAuth app ID. Search your Google Workspace admin console for the compromised OAuth application: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. If it appears, revoke it immediately and investigate what it accessed.
5. Review deployment logs. Look for any deployments in the past two weeks that you did not initiate. Check for modified build commands, injected scripts, or changes to your deployment configuration.
6. Set Deployment Protection to Standard. Vercel's Deployment Protection feature restricts who can view and access your deployments. Set it to "Standard" at minimum and rotate any existing Deployment Protection tokens.
7. Audit third-party AI tool access. Check your Google Workspace and GitHub OAuth authorisations. Revoke access for any AI tool that does not have explicit organisational approval. This is not just about Context.ai - it is about every tool in the same category.

The Three Lessons That Matter Beyond This Incident

1. Your Security Perimeter Now Includes Every AI Tool Your Team Uses

The traditional security model thinks about your code, your infrastructure, your network. The modern reality is that your attack surface includes every SaaS tool, every browser extension, and every AI assistant that any employee has granted OAuth access to. Security teams need to start treating AI tool governance with the same rigour they apply to infrastructure access. That means an approved tools list, regular OAuth audits, and a clear policy on what permissions AI tools can be granted.

2. Defaults Matter More Than Documentation

Vercel had a "sensitive" flag for environment variables. It was documented. It was available. And almost nobody used it, because the default was non-sensitive and the non-sensitive path was easier. This is not a user education problem - it is a product design problem. When the secure option requires extra steps and the insecure option is the default, you have built a system that optimises for breaches.

If you are building a platform that stores customer secrets, the secure storage option should be the default. Full stop. Making users opt-in to security is making them opt-out of being compromised, and most of them will not bother.

3. Supply Chain Attacks Have a New Favourite Target

We spent the last few years worrying about npm supply chain attacks - compromised packages, typosquatting, malicious postinstall scripts. Those are still real threats. But this breach shows that the supply chain attack surface has expanded to include the tools engineers use to write and deploy code, not just the code itself. An AI tool compromise gives an attacker access to the human, not just the codebase. And the human has access to everything.

This Will Happen Again. The Question Is Whether You Are Ready.

I want to be clear about something: this is not a "Vercel is bad" article. Vercel's response has been reasonably transparent - they disclosed quickly, published IOCs, engaged Mandiant, and provided actionable remediation steps. That is more than many companies do after a breach.

But this incident is a preview of a pattern we are going to see repeatedly over the next few years. As AI tools proliferate across every team in every organisation, the number of third-party OAuth grants is going to keep growing. Each one is a trust extension. Each one is a potential entry point. And the AI tool ecosystem is young, fast-moving, and not yet subject to the kind of security scrutiny that more mature SaaS categories face.

The companies building AI tools are optimising for adoption speed and feature velocity, not security hardening. That is understandable from a startup perspective. It is also a ticking time bomb from a security perspective. Context.ai is the first high-profile casualty. It will not be the last.

For frontend engineers specifically, this breach should trigger a broader conversation about where we draw trust boundaries. We moved our deployments to the cloud and trusted the platform. We moved our secrets to environment variables and trusted the storage. We moved our productivity to AI tools and trusted the OAuth grants. At each step, we traded direct control for convenience. And at each step, we expanded the surface area that an attacker could target without ever touching our code.

The answer is not to retreat to self-hosted everything - that creates its own security problems. The answer is to be deliberate about every trust extension. Audit your OAuth grants. Use sensitive storage for sensitive values. Rotate credentials regularly. And the next time someone on your team asks "can I try this cool new AI tool?", make sure the answer includes a security review - not just a "sure, go ahead."