In April 2026, Vercel was compromised via an OAuth app integrated into their Google Workspace tenant stemming from a compromised third-party AI SaaS provider.Here’s what you need to know.
In April 2026, Vercel was compromised via an OAuth app integrated into their Google Workspace tenant stemming from a compromised third-party AI SaaS provider.Here’s what you need to know.
This week, a user going by the name of “ShinyHunters” (though allegedly not actual ShinyHunters, but someone imitating them in an attempt to trade off their credibility) posted on a breach forum claiming access keys, source code, and database data allegedly stolen from cloud development platform provider Vercel.
This happened because a Vercel employee had connected an AI app, Context.ai, into their Google Workspace tenant. When Context.ai was compromised — allegedly the result of an infostealer infection from an employee searching for Roblox cheats — the attacker was able to leverage OAuth tokens stored in Context.ai’s Supabase platform to access downstream customer accounts (pointing to a heavily permissioned victim, probably a developer, possibly even a personal device with access to corp credentials).
This access included a Vercel employee’s Google Workspace account. This particular user had significant access to data and secrets in Vercel’s systems, including internal dashboards, employee records, API keys, NPM tokens, and GitHub tokens, which the attacker was able to exfiltrate, holding Vercel to ransom for $2 million.
How did this happen, and what could have stopped it?
From Vercel’s perspective, this attack could have been avoided had their employees been blocked from adding new OAuth integrations without admin approval (a toggle in their Google admin panel, and an essential control in a well-configured environment). Or, if the integration had been flagged in a routine audit and removed.
An all-too-common tale in the modern enterprise is the SaaS app that was trialled by a single employee, lightly used, integrated with core app tenants, and forgotten about — adding an invisible node to the organization’s attack surface.
It probably should have been removed, too. The particular OAuth app that was connected into the environment was a deprecated “AI Office Suite” product intended for consumer use. According to Context.ai, Vercel aren’t even a registered customer — adding more evidence that this was probably the result of a self-service trial that was subsequently forgotten about. That consumer product has also since been replaced by an enterprise product. But for whatever reason, the access hadn’t been revoked (from either side).
The elephant in the room is that Context.ai is an AI app. Most organizations are rightly nervous about employees adding unapproved AI SaaS into their environment. Having employees use shadow AI in the form of LLMs is one thing — users uploading sensitive data to unapproved apps or external tenants being the key concern. But OAuth grants are even more dangerous. Because if that app or vendor is compromised, the apps and accounts you’ve integrated it with are also at risk — which is what was exploited here.
Where’s the fault?
It’s easy to point fingers here. There are multiple control gaps and failures for both parties. Vercel should have disabled OAuth grants without admin approval, and regularly audited the connections in their environment. From a vendor's perspective, they could have also default applied a control that prevents secret environment variables from being read — which would have significantly reduced the impact to Vercel customers from the data breach.
Context.ai comes off worse. They could and should have had better separation of accounts and privileges — and if true, their users really shouldn’t be downloading Roblox scripts on devices they use for work access. It’s important to say if true here, but the prospect of third parties accessing your environment from insecure devices that they use for gaming is the stuff of nightmares for enterprise security and compliance teams.
You definitely don’t want to be Context.ai in this scenario. The reputational harm could be pretty significant, and is a wake-up call for other SaaS vendors to check that their house in order. But although Vercel have responded quickly and transparently to the incident, this could only really have happened as a result of technical and procedural control gaps on their end.
It’s worth taking a step back and looking at the bigger picture here — and how these issues might impact your organization too.
Shadow AI is still just shadow SaaS – but the AI scramble is a force multiplier
Shadow IT, and in particular shadow SaaS, is not a new problem. Most organizations run heavily (or exclusively) on SaaS, accessed in the browser, with hundreds of apps per enterprise. Unmanaged, self-adopted apps have been a thorn in the side of security teams for some time.
There are essentially three kinds of shadow IT to be wary of in this context:
Shadow apps: Apps that employees have signed up to and are using for business purposes without business approval. This includes apps signed up to with a corporate account or personal account.
Shadow tenants: Apps that employees are accessing with personal accounts, essentially creating shadow tenants outside of your organization’s control — even if you’ve approved the app itself.
Shadow integrations: OAuth connections across apps that aren’t known or approved. Even if an app itself is approved, plugging that app directly into your primary enterprise apps — with all the sensitive data and functionality therein — isn't necessarily also approved.
In the Vercel case, we’re talking about shadow integrations. These are easy to introduce and hard to control across apps. While enterprise cloud platforms like Microsoft and Google do give admins the ability to audit and control OAuth connections, the Vercel breach shows how secure settings aren’t always on by default. And SaaS-to-SaaS connections are even less visible, often with fewer controls.
The web of OAuth sprawl spans way beyond Google and Microsoft
On average we see 14 unique AI app integrations per organization in Microsoft and Google alone. If you consider that most organizations have probably approved 1 or 2 max for business use, and may have approved none at all for app-to-app OAuth connectivity, that’s quite a significant difference.
The number of connections outside of these core platforms is significantly higher. Just think how the typical AI app operates. If you want it to be able to effectively automate workflows — pull data from one app, aggregate and analyze it in another, present that information in a report, dashboard, or presentation, and then distribute it — that’s a fair few integrations in just one workflow. MCP connections use OAuth to achieve this interconnectivity in the same way as any other SaaS app.
We used to talk about automation apps like Zapier as being a goldmine for attackers. Well, AI apps are on their way to being even more interconnected, more frequently used, and more flexible in terms of how attackers can abuse them.
OAuth breaches are stacking up
Widespread OAuth interconnectedness isn’t just an AI app problem. Attackers have been exploiting this for some time:
In 2025, Scattered Lapsus$ Hunters launched OAuth-driven supply chain attacks against Salesforce and Google Workspace tenants after breaching Salesloft (specifically the Salesloft Drift platform) and Gainsight. In total, over 1000 organizations were impacted, including Google, Cloudflare, Rubrik, Elastic, Proofpoint, JFrog, Zscaler, Tenable, Palo Alto Networks, CyberArk, BeyondTrust, Qualys, and many more, with over 1.5B records stolen.
More recently, Snowflake customers were impacted after a breach at data anomaly detection company Anodot where the attacker attempted to leverage the stolen authentication tokens to access Salesforce data, with Rockstar a high-profile victim of the breach (again linked to Scattered Lapsus$ Hunters).
Not only are attackers abusing existing (legitimate) OAuth connections as part of supply chain attacks, but they’re using OAuth-focused phishing as the front door to victim environments. Last year’s Salesforce campaign began with device code phishing, where attackers tricked victims into registering an attacker-controlled app into their Salesforce tenant, granting full API access for mass data exfiltration.
Infostealers continue to drive corporate breaches
While unverified, Hudson Rock’s case for an infostealer breach being the root cause of the Context.ai breach seems believable. Infostealer infections have been one of the leading security threats for some time, fuelling breaches powered by stolen credentials and session tokens.
With the assumed rise in MFA coverage, it’s often surprising to security teams that stolen credentials are still a problem. But of the last million logins we saw, 1 in 4 were password logins (not SSO), 2 in 5 were not protected by MFA, and 1 in 5 used a weak, breached, or reused password. Plenty of scope for abuse.
Stolen session tokens are even more valuable to attackers, enabling them to bypass authentication controls by replaying the token in their own browser. In theory, they should only be valid for a limited timeframe, but in practice this can be as many as 90 days, and sometimes indefinite.
In this case, it seems likely that the compromised device was a developer machine (given the access to Supabase), or potentially even a personal device (given they were installing Roblox cheats…). This is relevant because these personal, developer, and BYOD machines are often less secure — developer machines are often exempt from EDR monitoring or significantly tuned-down (too noisy), while personal devices naturally lack enterprise security software.
If you’re wondering how a personal device could result in corporate credential leakage, browser syncing (where users sign into their personal account in a corporate browser) can lead to this exact scenario. And given Vercel’s potentially lacking controls around OAuth integrations in their Workspace, it’s also possible that browser syncing had not been identified as a security risk and disabled.
The 2025 Verizon DBIR reported that 54% of all ransomware attacks traced back to infostealer-enabled credential theft. 46% of systems with compromised corporate credentials were non-managed devices.
We’ve also seen an uptick in developer-oriented phishing and malvertising campaigns. The InstallFix campaign we identified, intercepting users as they attempt to install AI tools like Claude Code and NotebookLM, is an example of this — and also another way that attackers are capitalizing on AI hype.
Advice for security teams
There are some immediate next steps that we’ll quickly summarize here, as they've already been covered in wider reporting. If you’re a Vercel customer, you should urgently rotate every credential stored as a non-sensitive variable that could have been exposed, enable the sensitive variable feature toggle, and monitor your account for anomalous activity. And if you’re using the specific Context.ai integration, you need to revoke it ASAP and begin a full audit of the connected accounts, both inside Workspace and broader connected apps (this isn’t that easy, as we’ll highlight in a moment).
OAuth App: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
Taking a step back, organizations really need to get their arms around OAuth integrations in their environment. A default-deny approach to allowing users to consent to new integrations, and routinely auditing the ones already in your environment to ensure they’re still definitely required, is essential. Each integration expands your attack surface and could potentially grant an attacker extensive access to your environment. This default-deny approach isn't exactly a new concept for security teams and is the same in principle as what we recently advised for browser extension management.
This is fairly straightforward in your main enterprise cloud environment (think M365 or Google Workspace). But doing it across every SaaS app that allows some level of OAuth integration with another (i.e. every SaaS app) is somewhat harder. Not only do you need to have a comprehensive and up-to-date inventory, you need to be an app admin for every app (not always the case for self-adopted apps) and the particular app needs to give you the control to restrict and remove OAuth grants on behalf of users in your tenant.
Again, this is not exclusively a Shadow AI problem, even if AI adoption is contributing significantly to the sprawl.
Since the breach was initially reported, it has also emerged that Context.ai’s browser extension has also been pulled from the Chrome store. It’s unclear whether attackers were able to publish a malicious extension update too, whether the extension was removed at Context.ai’s request (because the app has been deprecated), or Google pulled it down as a precaution in light of the incident.
How Push can help
As we’ve established, there are quite a few pieces to this puzzle. Push can help with all of them.
Push observes every app login your employees make in their browser, building a comprehensive picture of SaaS and AI use across your organization. This includes how they’re logging in and how secure the login is: did it have MFA, what kind of MFA, was it using a weak or compromised password, did they use SSO, and so on.
Push also tracks OAuth integrations in your environment and gives you the ability to manage and remove them in core environments like M365 and Google Workspace, providing a single platform for you to view, manage, and secure app use across your organization.
This makes it easy to surface both vulnerabilities and possible control gaps, and do something about them. But where Push really excels is in the ability to observe and block OAuth connection requests even outside of your primary enterprise apps. Using Push, you can detect and block OAuth integration requests as they traverse the browser. This app-agnostic level of control is absolutely critical to halting OAuth integration sprawl.
And that’s not all …
Push’s browser-based security platform also detects and blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, device code phishing, ClickFix, and session hijacking in real time. This includes the most prominent infostealer delivery vectors in terms of malvertising and *Fix-style attacks. Push analyzes every web page in every browser session and tab for threats, in real time, with no latency.
But as we've established, you don't need to wait until it all goes wrong either — you can use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, risky OAuth integrations, and more to harden your attack surface.
To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.
