Introduction

On April 19, 2026, Vercel disclosed a security incident originating from the compromise of Context.ai, a third-party AI tool. An attacker exploited a compromised OAuth 2.0 application registered by Context.ai to take over a Vercel employee’s Google Workspace account, gaining access to certain internal environments and a subset of customer data.

This incident is the latest in a growing pattern of OAuth 2.0-based supply chain attacks. From the Chrome extension breaches in late 2024 to the Entra ID consent injection attacks we covered previously, attackers are increasingly targeting the trust relationships built into OAuth 2.0 rather than breaking through traditional perimeters.

Vercel assessed the attacker as “highly sophisticated based on their operational velocity and detailed understanding of Vercel’s systems.” They’ve engaged Mandiant and notified law enforcement, but the incident raises critical questions for every organization: how do you detect a rogue OAuth app before it becomes a breach?

How the attack worked

The Vercel breach followed a multi-stage supply chain path. Piecing together disclosures from Vercel, Context.ai, and independent research by Hudson Rock, here is what we know so far.

What we know

The initial compromise was an infostealer, not a sophisticated exploit. A Context.ai employee with administrative privileges — using the [email protected] account, described as belonging to a “core member” of the team — was infected with Lumma Stealer in February 2026. According to Hudson Rock, the employee had been downloading malicious Roblox “auto-farm” scripts. The malware exfiltrated browser credentials, session cookies, and OAuth tokens, including credentials for Google Workspace, Supabase, Datadog, and Authkit.

The compromised employee had direct access to Context.ai’s Vercel environment. Browser history logs from the infected machine showed access to sensitive Vercel-hosted endpoints for Context.ai’s organization (context-inc), including:

• vercel.com/context-inc/valinor/settings/environment-variables — where API keys and deployment secrets reside
• vercel.com/context-inc/valinor/settings — project configuration
• vercel.com/context-inc/valinor/logs — production logs enabling environment enumeration

Context.ai’s AWS environment was breached. Context.ai confirmed that an unauthorized actor gained access to their AWS environment and compromised OAuth tokens for some of their consumer users.

A Vercel employee had granted “Allow All” permissions. At least one Vercel employee signed up for Context.ai’s AI Office Suite using their Vercel enterprise Google Workspace account. Context.ai’s own disclosure noted that “Vercel’s internal OAuth configurations appear to have allowed this action to grant these broad permissions in Vercel’s enterprise Google Workspace.”

The attacker used a compromised OAuth token to access Vercel’s Google Workspace, gaining entry to certain internal systems and environment variables that were not marked as “sensitive.” The OAuth application involved has been identified by its client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. The application’s Chrome extension was removed from the Chrome Marketplace on March 27, and Google subsequently deleted the account. Hudson Rock had possessed the compromised credential data over a month before Vercel confirmed the breach highlighting the detection gap that allowed the supply chain escalation to succeed. The stolen data is now being sold by the ShinyHunters group.

What we can reasonably infer

The exact OAuth scopes granted to Context.ai’s application have not been disclosed. However, several data points allow us to narrow this down considerably.

Context.ai’s AI Office Suite was described as a tool for building documents, presentations, and spreadsheets, with AI agents that could “perform actions across external applications.” For this to function with Google Workspace, the application would have needed, at minimum, access to Google Docs, Sheets, Slides, and Drive APIs.

The employee granted “Allow All” permissions — meaning they accepted every scope the application requested without restriction. Reporting from Help Net Security indicates that the sensitive scopes included gmail.readonly, calendar, drive, and admin.directory.

Given the product’s functionality and the “Allow All” grant, the scopes likely included some combination of:

The broader lesson: every OAuth scope granted to a third-party app is an implicit trust delegation. When that third party is compromised, the scope becomes the blast radius.

Why OAuth 2.0 supply chain attacks are so dangerous

The fundamental issue is the trust model. When a user authorizes an OAuth 2.0 application, they are granting that application ongoing access to specific resources on their behalf. That grant persists until explicitly revoked — and the user is trusting not just the app developer, but their entire security posture.

This creates a transitive trust problem:

• User trusts App → User grants OAuth scopes to the app
• App gets compromised → Attacker inherits all granted scopes for all users
• Attacker accesses resources → Using legitimate tokens that don’t trigger traditional security alerts

A compromised OAuth credential pair is long-lived. Once it is stolen, the attacker can use it until it is explicitly revoked.

This is exactly what happened here. Gmail read access alone could yield credentials, internal documents, API keys, and enough context to understand Vercel’s internal systems — exactly the “detailed understanding” Vercel described in the attacker’s profile. Directory access could reveal the organizational structure and identify high-value targets. And Drive access could expose shared documents containing architecture diagrams, runbooks, or credentials stored in spreadsheets — a practice that remains disturbingly common.

Detecting these attacks without SlashID

Organizations without specialized identity threat detection tooling can still look for indicators of compromise, but it requires significant manual effort.

1. Review OAuth app grants in Google Admin Console

Google Workspace admins can view authorized third-party apps in the Admin Console under Security → API Controls → Third-party app access. For each app, you should:

• Identify the scopes granted
• Verify the app is still legitimate and actively used
• Cross-reference the app’s client ID against known IOCs

In this case, the IOC published by Vercel is:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

2. Audit OAuth token activity logs

Google Workspace provides audit logs for OAuth token grants. Look for:

• New OAuth grants to previously unseen applications
• Apps requesting unusually broad scopes (e.g., full Gmail access for a tool that should only need calendar access)
• Grants occurring outside normal business hours or from unusual geolocations

The challenge

The problem with this approach is scale and speed. Most organizations have dozens or hundreds of third-party OAuth apps authorized across their workforce. Manually reviewing each app’s scopes, cross-referencing IOCs, and correlating activity logs is time-consuming and error-prone. By the time a security team identifies a compromised app through manual review, the attacker has likely already achieved their objectives.

Detecting and responding with SlashID

SlashID provides three capabilities that directly address this attack pattern:

1. Identity Graph: full visibility into OAuth app grants

SlashID’s Identity Graph provides a unified view of every OAuth 2.0 application authorized across your organization, the scopes each app holds, and which users have granted access.

Rather than clicking through individual apps in the Google Admin Console, you get a single view that shows:

• Every third-party OAuth app and its granted scopes
• Which users have authorized each app
• When the grants were made
• Whether the scopes include dangerous permissions

When an IOC like the Context.ai client ID is published, you can immediately identify every affected user in your organization and understand exactly what level of access was exposed.

2. Built-in detections for risky OAuth scopes

SlashID provides built-in detections across IdPs for risky scopes and anomalous OAuth 2.0 apps. These detections fire automatically — no custom rules needed.

Specifically, SlashID detects:

• Risky OAuth scope grants: Apps requesting high-privilege scopes like full email access, directory management, or drive write access
• Anomalous OAuth 2.0 applications: New or unrecognized apps appearing across your identity graph
• Scope escalation: Apps that previously held limited scopes suddenly obtaining broader permissions
• Bulk grant patterns: A single app rapidly accumulating grants across multiple users (a hallmark of phishing campaigns)

In the Vercel case, SlashID would have flagged Context.ai’s OAuth application if it held dangerous scopes like mail.google.com or admin.directory.user — providing an early warning before the upstream compromise even occurred.

3. Automated remediation: find and revoke dangerous scopes

Once a compromised app is identified, SlashID enables immediate remediation. You can revoke access to the app either automatically through our remediation capabilities.

Finding all apps with dangerous scopes:

Using SlashID’s AI Query Assistant, you can search for all OAuth 2.0 grants with specific dangerous scopes across your entire identity graph spanning Entra/Azure, Okta, Google Workspace, Salesforce, and more in a single query. For example, querying for all grants with the scope Directory.Read.All:

The query checks across multiple scope-related properties using case-insensitive matching and retrieves the associated principal (identity) each grant belongs to, along with metadata like application name, resource name, and consent type. You could run similar queries for gmail.readonly, drive, or any other scope that appeared in the Context.ai breach.

Revoking access:

For a specific compromised app, you can:

1. Identify all affected users through the Identity Graph
2. Trigger a bulk revocation of the app’s OAuth grants across all users

Recommendations

Regardless of what tooling you use, the Vercel incident highlights several important practices:

1. Audit your OAuth app grants today. Identify every third-party app with access to your Google Workspace (or Microsoft Entra, Okta, etc.) and review the scopes. Remove apps that are no longer in use or that hold overly broad permissions.

2. Rotate exposed credentials. If your organization used Context.ai, rotate any secrets that may have been accessible through the compromised Google Workspace account especially API keys, and access tokens.

3. Treat OAuth grants as part of your attack surface. Every third-party OAuth app is a potential supply chain entry point. Apply the same rigor to OAuth app management that you apply to vendor security reviews.

4. Implement continuous monitoring. One-time audits are insufficient. Continuous monitoring for risky scopes and anomalous apps is essential.

Conclusion

The Vercel incident is a clear example of how identity infrastructure, in this case OAuth 2.0 trust relationships, has become a primary attack vector. The attacker didn’t exploit a zero-day or brute-force a password. They compromised a third-party app and inherited the trust that employees had already granted.

This pattern will continue. As organizations adopt more SaaS tools, AI assistants, and third-party integrations, the sprawl of OAuth grants grows. Defending against these threats requires continuous visibility into your OAuth app landscape, automated detection of risky scopes, and the ability to revoke access at speed.

Contact us if you’d like to see how SlashID can help you detect, investigate, and remediate OAuth-based supply chain attacks before they become breaches.