AI extension OAuth tokens: how to audit your connected apps after the Vercel breach

A cloud hosting company you've probably used got breached this spring. The starting point wasn't a Vercel server. It wasn't a Vercel employee falling for a phishing email. It was a Chrome extension that one of their engineers had connected to their corporate Google account through an extension OAuth grant — an extension built by a different company entirely, whose own employee had been infected with infostealer malware months earlier.

The chain ran: Roblox cheat script → Lumma infostealer → stolen Context.ai employee credentials → Google Workspace OAuth tokens → Vercel employee's corporate account → Vercel's internal systems → customer environment variables and credentials. Three different companies, one Chrome extension, one OAuth grant. That's the supply chain that mattered.

If you've ever clicked "Allow" on a Chrome extension asking to connect to your Google Workspace, this is your story too.

What actually happened

According to Vercel's own bulletin, the company confirmed a security incident in April 2026 affecting a limited subset of customers. Customer environment variables not marked as sensitive and Vercel credentials were exfiltrated. TechCrunch and BleepingComputer both reported the attacker showed up on BreachForums asking $2 million for the stolen data.

Vercel CEO Guillermo Rauch then did something most CEOs avoid: he publicly named the third-party source. The Register reported that the breach was traced to Context.ai, an AI productivity suite whose Chrome extension was installed by at least one Vercel employee. Per Vercel's bulletin and Help Net Security's coverage, a Context.ai employee's machine was infected with the Lumma infostealer in February 2026 after downloading malicious Roblox "auto-farm" scripts. That infection harvested the employee's session tokens and OAuth credentials.

Hudson Rock identified the infostealer linkage. Nudge Security's CTO publicly identified Context.ai as the compromised third party. From there, attackers used the stolen Context.ai OAuth tokens to pivot into a Vercel employee's connected Google account — the OAuth scopes that Context.ai had requested at install time were broad enough to make that pivot work — and from the employee's Workspace, they reached Vercel's internal systems.

Google removed the Context.ai Chrome extension from the Chrome Web Store on March 27, 2026, weeks before Vercel disclosed the incident publicly on April 20. As of writing, Context.ai has not publicly responded with detailed remediation guidance for affected users.

The Roblox script angle isn't a joke

The initial infection vector wasn't a sophisticated phishing kit. It was Roblox cheat scripts. Per The Register's reporting, a Context.ai employee — on what was almost certainly a personal browsing session — downloaded malicious "auto-farm" tooling popular in the Roblox community.

Lumma stealer's wide deployment across gaming, cracking, and warez forums means it lands on personal devices constantly. When that personal device also has access to corporate credentials — through saved Chrome passwords, signed-in Google Workspace sessions, or extension OAuth tokens — the boundary between "personal browsing" and "work systems" collapses. It's the same sideloaded-trust failure I traced in the Snowbelt enterprise extension attack.

This is why the Vercel breach matters beyond Vercel. The same trust chain runs through hundreds of AI productivity extensions installed across every company that lets employees use Chrome at work. An infostealer on any one of those developers' machines becomes a key to every Workspace those developers' extensions touch. And because the developer is, by definition, an organization small enough to ship a Chrome extension without a dedicated security operations team in most cases, "the developer's personal device hygiene" is now part of your company's threat model whether you wanted it to be or not.

Why this matters for you

When you install an AI extension and it asks to connect to your Google Workspace, you're handing over a permanent-feeling key. OAuth tokens don't typically expire on a short cycle. They sit in the extension developer's backend infrastructure indefinitely, refreshing on demand, granting whatever scopes you originally approved — Gmail read, Drive read, Calendar read, sometimes write access too.

That key isn't held just by you. It's held by the developer who built the extension. If that developer's laptop gets infected — through their kid's Roblox session, a downloaded crack, a malicious npm dependency, anything — every OAuth token they're managing on behalf of their users is now an asset the attacker can use.

The blast radius isn't the developer's company. It's every company whose employees ever clicked "Allow" on that consent screen. If you're cleaning up after a hit like this, my AI extension incident response playbook walks through the containment steps in order.

This is the same trust math I covered in my earlier piece on the <all_urls> host permissions problem, but moved up one layer. There, the risk was the extension reading your local browser context. With Workspace OAuth, the extension's reach extends beyond your browser into your company's email, files, calendar, and identity systems — and that reach persists even after you close the tab or uninstall the extension, unless you actively revoke the grant.

How to audit your extension OAuth grants

Here are the steps I'd run through right now if I had a Workspace account at any company.

Check what's actually connected to your Google account. Go to myaccount.google.com/permissions. This shows every third-party app that holds an OAuth grant — including extensions that requested Workspace access. Look for AI assistants, "AI writers," meeting note-takers, email summarizers, calendar AI, sales automation, and anything else with broad Gmail or Drive scopes.

Revoke anything you don't actively use today. Revoking doesn't just disable the integration — it invalidates the refresh token, so even if the developer's backend is compromised later, your data is out of reach.

Audit by scope, not by name. When you review each app, click into the details and read which scopes it was granted. "Read, compose, send, and permanently delete all your email" is not the same as "send email on your behalf." The first is a full Gmail clone running on the developer's servers. If an AI extension that just summarizes pages somehow has Gmail read access, that's the audit failure that puts you in the next Vercel-style headline.

Treat extensions and OAuth grants as two separate things. Uninstalling a Chrome extension does not automatically revoke its OAuth grant. The extension is gone from your browser, but the developer's backend still holds tokens that work. I've seen this catch enterprise security teams during incident response — they assume "uninstalled" means "no longer connected." It doesn't. Always revoke explicitly via the Google account permissions page, and do it before you uninstall, not after, so you don't forget once the icon disappears from your toolbar.

Look at the developer's company, not just the product. Before you install a new AI extension, spend two minutes searching the developer's company name plus terms like "breach," "incident," "infostealer," and "compromise." If their security operations posture is shaky for any other reason — a small team, no security page, no SOC 2, no public response when researchers report bugs — the Vercel chain is a plausible failure mode. You're trusting their device hygiene, not just their code.

Watch for OAuth refresh notifications. Google sends an email when an app refreshes its access or when something looks anomalous. Don't let those notifications pile up in a "Notifications" filter you stopped reading in 2023. If an extension you don't recognize suddenly refreshes its OAuth grant from a country you've never been to, that's the signal that matters.

How Extenshi helps

Most users never look at extension permissions until something goes wrong. We built the Extenshi catalog so the permissions, OAuth scopes, and ownership history of every extension are visible before you install — and so you can monitor what's already running. When an extension in our catalog gets pulled from the Chrome Web Store (the way Context.ai's was on March 27), or when its developer ships an update that quietly expands its scopes, that's the kind of signal we surface so you don't find out about it from a breach disclosure six weeks later.

If you use AI extensions in a corporate Google account, this is a good week to audit. Pull up your installed extensions, cross-reference them against your Google permissions page, and revoke anything you don't need.

Scan your extensions →

For a broader picture of what extensions are doing inside your browser right now — including which ones request the kind of broad scopes that turn into supply chain pivot points — browse the Extenshi catalog and check the security report on the AI tools you have installed.

---

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].