Context.ai OAuth Token Compromise

Compromised Context.ai OAuth tokens enabled attackers to perform a supply chain attack via trusted SaaS integrations. Learn how to assess the risk in your environment and how to prevent the next attack.

On April 19th, 2026, Verceldiscloseda security incident involving unauthorized access to their internal systems. According to their incident report, the attacker compromised an employee’s Google Workspace account via a third-party AI tool named Context.ai, who have since confirmed that their consumer-focused AI Office Suite environment was indeed compromised. This incident is in effect a double supply chain attack, where access to Context.ai was leveraged to gain access to their customers, including Vercel, and then Vercel’s customers.

For more information and guidance related to Vercel’s security incident, seetheir advisory.

Context.ai disclosed that they determined that OAuth tokens for some consumer users were likely compromised as a result of this incident. According to their statement, at least one Vercel employee had authorized the affected OAuth application with broad (“Allow All”) permissions, which enabled the attacker to leverage the stolen token to access Vercel’s Google Workspace.

Public reporting by Hudson Rock hasnotedthat a recent infostealer infection of a Context.ai employee may have been leveraged to gain access to Context.ai's internal systems and ultimately acquire the OAuth application credentials, but this remains unconfirmed.

This activity hasn’t been attributed to a specific threat actor, but an actor claiming to be associated with ShinyHunters has claimed responsibility for Vercel’s incident. However, these claims remain unverified, and the group may have been impersonated by a copycat.

This campaign aligns with a broader class of attacks abusing trusted third-party OAuth integrations as an initial access vector. In similar incidents, such as theSalesloft Drift incidenttargeting Salesforce environments, attackers leveraged compromised OAuth tokens from a third-party provider to access downstream SaaS platforms and exfiltrate data via legitimate APIs. This tradecraft has also been observed in state-aligned activity, including theMidnight Blizzard campaignagainst Microsoft, where OAuth applications were abused to maintain persistent access to enterprise environments. Rather than exploiting vulnerabilities in the primary platform, these attacks rely on pre-authorized access and delegated permissions, enabling stealthy lateral movement and expanding the blast radius across multiple organizations that trusted the same integration. For additional background on detection and abuse patterns, see Wiz’s research onmalicious OAuth applicationsandOAuth-based attack techniques.

Security teams should approach this incident as a third-party OAuth compromise with potential downstream impact across multiple SaaS platforms. Response efforts should focus on three parallel tracks: (1) identifying and revoking access to the compromised Context.ai application across identity providers, (2) assessing potential exposure by rotating credentials and tokens associated with affected users, and (3) investigating account activity for signs of misuse or data access. Given the nature of OAuth-based access, particular attention should be paid to cross-application activity and any services accessible through delegated permissions.

Check if the Context.ai OAuth app is authorized in your environment. Navigate to Admin Console → Security → API Controls → Manage Third-Party App Access and search for "Context" or the OAuth Client ID.

Search for authorization events across all users:

For each identified user, check if the token is still active:

Review the response for any token where clientId contains110671459871.

If present: revoke the grant immediately via Admin Console → Security → API Controls. Rotate Google Workspace credentials and any linked SaaS/API tokens for all affected users.

Context.ai offered Azure AD SSO integration configured as a per-tenant SAML SSO application. Search by name or by Context.ai's Entra tenant identifiers:

d06415cc-3d2c-4ffd-940e-76e35cef3a46(context.ai domain)

008dd1ce-2db3-4ffa-b318-0f52bc4c3a82(context.inc domain)

Or via PowerShell:

Or via Azure CLI:

If found: delete the service principal via Entra ID → Enterprise Applications. Rotate credentials for all assigned users.

Navigate to Applications → Applications and search for "Context".

If found: remove the app assignment and rotate credentials for all assigned users.

For each user identified in the previous section, investigate activity across Google Workspace services that were accessible via the OAuth grant. Review the scope field in the authorization event to determine which services to prioritize.

If your Google Workspace logs are ingested into GCP, you can use the Log Explorer to identify the application’s activity via the following query-

https://console.cloud.google.com/logs/query;query=protoPayload.methodName%3D~%22%2528google.identity.oauth2.GetTokenInfo%7Cgoogle.identity.oauth2.GetToken%2529%22%0AprotoPayload.metadata.event.parameter.value%3D%22110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com%22%0AprotoPayload.serviceName%3D%22oauth2.googleapis.com%22;summaryFields=protoPayload%252Fmetadata%252Fevent%252F0%252Fparameter%252F1%252Fvalue:false:32:beginning;cursorTimestamp=2026-04-20T11:39:11.204987Z;startTime=2026-03-19T23:00:11.262Z;endTime=2026-04-20T11:39:11.262Z?referrer=search&hl=en&organizationId=<ORG-ID>

Investigate app activity: Validate source IP and audit user actions. -

https://console.cloud.google.com/logs/query;query=protoPayload.authenticationInfo.principalEmail%3D%22<USER_EMAIL>%22%0AprotoPayload.requestMetadata.callerIp%3D%22<IP_ADDRESS>%22;cursorTimestamp=2026-04-20T11:39:11.034112Z;startTime=2026-03-19T23:00:11.262Z;endTime=2026-04-20T11:39:11.262Z?referrer=search&hl=en&organizationId=<ORG_ID>

Review the output for anomalous patterns: unexpected volumes of API calls, activity from IP addresses that don't match the user's normal sign-in locations, or access to services outside the user's typical usage patterns.

If affected users had access to cloud environments (AWS, GCP, Azure), review those logs for anomalous activity as well.

Rotate environment variables, while prioritizing those not marked as "sensitive", as these may have been accessible during the incident. In Vercel, variables marked as “sensitive” are stored and handled in a way that prevents them from being read or enumerated, even if an attacker gains access to environment configuration interfaces

Review activity logs and deployments for suspicious behavior

Enforce use of "sensitive" environment variables for all secrets. This control limits the blast radius of similar attacks by preventing direct exposure of secret values. This is a preventative measure for future protection. Marking variables as sensitive does not mitigate exposure in this incident for any values that were previously stored as non-sensitive and may have already been accessed

Rotate Deployment Protection tokens and validate configuration

Wiz customers can use the pre-built query and advisory in theWiz Threat Intel Centerto search for relevant instances in their environment.

Context.ai security update

Vercel bulletin

Hudson Rock Infostealers blogpost

Guillermo Rauch X post

GCP documentation

Azure documentation

Okta documentation

Extending Wiz Visibility with the Databricks Data & AI Platform

Threat actors have moved upstream, and while security teams have focused on the code developers write, the systems that build and deliver that code have remained a blind spot.

As AI applications introduce a new class of infrastructure resources, visibility into what your IaC creates, where it runs, and whether it has drifted has never been more critical.

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings