Vercel Breach Tied to Context.ai Hack: How an AI Tool OAuth Token Became a Supply Chain Backdoor

What happened

On Sunday, April 19, 2026, Vercel started publishing a live-updated bulletin on its knowledge base. The first entry, at 11:04 AM PST, listed indicators of compromise. Seven hours later, at 6:01 PM PST, Vercel named the upstream vendor: Context.ai, a small AI "office suite" product that one of its employees had connected to their Vercel corporate Google Workspace account.

By Monday afternoon, TechCrunch, The Register, BleepingComputer, CyberScoop, and Help Net Security had confirmed the shape of the incident. A threat actor branding themselves as ShinyHunters put Vercel data up for sale on a cybercrime forum for roughly 2 million dollars — access keys, source code, database data, NPM and GitHub tokens, and a record of around 580 Vercel employees. The real ShinyHunters operators later told BleepingComputer they were not involved. Google Threat Intelligence assessed the lister as an imposter using the name.

Vercel says the incident affected a "limited subset" of customers but has not released a number. CEO Guillermo Rauch told TechCrunch that hundreds of users across many organisations were potentially exposed through the Context.ai compromise itself.

The attack chain

The chain reads like a stress test of every fashionable 2026 security risk in one incident.

In February 2026, a Context.ai employee searched for Roblox game exploit scripts on a work-adjacent machine. That search led to Lumma Stealer, an infostealer that scrapes browser credentials, session cookies, and saved API keys. Hudson Rock traced the infection and published the finding through InfoStealers.com, and CyberScoop confirmed it independently.

In late March 2026, the attacker used those stolen credentials to enter Context.ai's AWS environment. Context.ai engaged CrowdStrike and initially told one customer that their data had been touched. The company later conceded that OAuth tokens for consumer users had probably been compromised as well.

That second set of tokens is where Vercel enters the story. A Vercel employee had signed up for the Context.ai "AI Office Suite" using a Vercel corporate Google Workspace account. During onboarding, Context.ai asked for "Allow All" scope on Google Workspace, including full read access to Google Drive. The employee granted it. Vercel's Google Workspace configuration did not block the grant.

Once the attacker had that OAuth token, they took over the employee's Workspace account and moved laterally into Vercel's internal environments. There, they enumerated environment variables — and this is the detail that matters. Variables stored in Vercel's "sensitive" class are encrypted at rest and cannot be read by humans or services after the initial write. The attacker could not read those. Everything else, including API keys, database credentials, and third-party tokens that teams had stored without toggling the sensitive flag, was exfiltrated from a limited subset of customers.

What was and was not accessed

The malicious Google Workspace OAuth app ID Vercel published as the primary indicator of compromise is 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. If your Workspace has ever authorised that app, assume the associated account's session data was within reach.

Why this matters beyond Vercel

Vercel is the canonical modern hosting platform for Next.js applications. A lot of what looks like a regular business website in the Maldives is, under the hood, a Next.js site running on Vercel. Resort booking portals, fintech landing pages, government service microsites, e-commerce fronts for SMEs. If your developers or a vendor deployed your website in the last three years, there is a meaningful chance it is on Vercel, and there is an even higher chance that whoever built it stored API keys in environment variables without thinking about the "sensitive" flag.

This is also not the first time in the last eighteen months that a SaaS-to-SaaS OAuth token has been the pivot point. The pattern is becoming the default:

The new twist with Context.ai is that the poisoned upstream was an AI productivity tool. This matters because AI tools are the category of software employees self-enrol in fastest, and usually without a security review. An employee who would never install a random browser extension on a corporate laptop will happily connect a new AI scheduling, writing, or meeting-notes app to their Google Workspace in thirty seconds, because the friction is near zero and the productivity promise is immediate. Context.ai is not a household name. It was not on anyone's vendor register. The moment someone connected it with "Allow All", it was effectively a sanctioned bearer token for that employee's entire Workspace.

What this means for organisations in the Maldives

Three concrete implications:

1. Any Maldives organisation running production on Vercel should act this week. Rotate API keys for Supabase, Stripe, Firebase, database connection strings, payment gateway tokens, and anything else your team put into environment variables without clicking the "sensitive" toggle. Re-mark credentials as sensitive going forward. Enable MFA on all Vercel accounts. Review deployments and activity logs for the last 90 days. If you run Deployment Protection, rotate its tokens too.

2. MMA-regulated banks and fintechs should treat this as an OAuth governance drill. The MMA IT Risk Management Guidelines already require oversight of third-party technology providers, but that oversight typically covers core banking, card processors, and cloud infrastructure. OAuth grants to AI productivity tools rarely appear on the inventory, because no contract was signed and no invoice was raised. That is the gap the Context.ai incident exploits. Run an admin-level report of every third-party app with OAuth scope on your corporate Google Workspace or Microsoft 365 tenant. For each one, record who authorised it, what scopes it holds, when it was last used, and whether the vendor has a published security posture.

3. Resorts, tour operators, and SMEs need to know what their web vendor uses. If your resort's booking site was built by an outside developer, ask two questions. Is it hosted on Vercel? And if so, were any credentials stored without the sensitive flag? If the developer cannot answer within a day, treat it as a yes and rotate anyway. The cost of rotating keys is an afternoon. The cost of a leaked reservation database is an indefinite reputation problem.

This is the kind of exposure cloud security reviews are meant to surface before an incident forces the question.

What to do right now

For Vercel customers, the Vercel bulletin is explicit:

1. Audit your Google Workspace admin console for the OAuth app ID above. If present, revoke it on every account that has granted it.
2. Rotate every environment variable not marked sensitive across all projects. Treat them as exposed. This includes third-party API keys, database credentials, JWT secrets, OAuth client secrets, and webhook signing keys.
3. Re-mark all credentials as sensitive in Vercel's project settings so future exposure is scoped to encrypted storage only.
4. Enable MFA on all Vercel team accounts and review recent deployments for anything unexpected.
5. If you use Deployment Protection, rotate its tokens as well.
6. For crypto and Web3 teams, CoinDesk reported significant scrambling to lock down RPC endpoints and wallet-related secrets that had sat in non-sensitive variables. Rotate those too.

For everyone else, treat this as the forcing function to run a one-page OAuth audit on your Workspace and 365 tenants. Revoke dormant apps. Restrict "Allow All" or wildcard scope grants at the tenant level. Require admin approval for Drive read-all, Gmail read, or Directory scopes. Write down a rule that any AI tool connecting to corporate identity goes through security review before the button is clicked.

The uncomfortable lesson of the Vercel incident is that a single click by a single employee on a single AI productivity app, authenticated with a corporate Google account, can now be the only thing standing between an attacker and a platform that runs a quarter of the modern internet. The fix is not to ban AI tools. The fix is to treat OAuth grants on corporate identity as the privileged changes they have become.

Cybercloud Consulting works with organisations across the Maldives on exactly this kind of SaaS and cloud security posture. If you need help mapping your OAuth exposure, rotating secrets across a Vercel footprint, or standing up an AI tool vetting process that does not slow your teams down, get in touch.

References

1. Vercel April 2026 security incident bulletin — Vercel Knowledge Base, April 19–20, 2026
2. App host Vercel confirms security incident, says customer data was stolen via breach at Context AI — TechCrunch, April 20, 2026
3. Vercel Breach Tied to Context AI Hack — The Hacker News, April 2026
4. Vercel confirms breach as hackers claim to be selling stolen data — BleepingComputer, April 2026
5. Vercel breached via compromised third-party AI tool — Help Net Security, April 20, 2026
6. Vercel security breach linked to third-party Context.ai and Lumma Stealer — CyberScoop, April 2026
7. Vercel customers targeted after third-party tool compromised — Cybersecurity Dive, April 2026
8. Vercel security incident — The Register coverage — The Register, April 20, 2026
9. Hack at Vercel sends crypto developers scrambling to lock down API keys — CoinDesk, April 20, 2026
10. Vercel Context AI supply chain attack analysis — Ox Security, April 2026