The Vercel OAuth Identity Compromise

In April 2026, a threat actor compromised Vercel developer infrastructure through an identity supply chain attack that never required stealing a single password. By exploiting a compromised third-party OAuth integration — Context.ai — the attacker inherited valid Google Workspace refresh tokens, bypassed multi-factor authentication entirely, and exfiltrated production secrets from internal dashboards. This incident represents a paradigm shift: the attack surface has moved from credentials to consent, and the blast radius extends to every application that trusts the identity provider.

The Valet Key Attack Chain

The compromise unfolded across four distinct phases, each exploiting a fundamental trust assumption in modern OAuth-based identity architectures. The attacker never needed to phish a credential — they inherited one.

POST https://oauth2.googleapis.com/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

client_id=110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
&client_secret=[REDACTED]
&refresh_token=[STOLEN_REFRESH_TOKEN]
&grant_type=refresh_token

// Response: fresh access_token valid for 3600 seconds
// No MFA challenge. No session validation. No user notification.

Attack Timeline

Indicators of Compromise

MITRE ATT&CK Mapping

Tactical Hunting: Google Workspace Log Queries

The following queries target Google Workspace Admin SDK and audit logs. They are designed to detect the specific patterns observed in this incident and should be adapted to your environment.

Query 1: Malicious OAuth Grant Detection

Detects OAuth consent grants to the known compromised Context.ai Client ID via the Google Workspace Authorize API Site event.

event_name = "authorize"
AND api_name = "API Site"
AND client_id = "110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com"

// Returns: user, timestamp, scopes granted, IP address
// Action: Any match confirms prior consent to the compromised app.
// Immediately revoke the token and investigate the account.

Query 2: Token Anomaly — High-Privilege Account Refresh Activity

Identifies unusual token refresh patterns from accounts with elevated privileges — a key indicator of stolen refresh token abuse.

event_name = "token_refresh"
AND actor.is_admin = true
AND (
    ip_address NOT IN [corporate_ip_ranges]
    OR geo.country NOT IN [expected_countries]
)
GROUP BY actor.email, client_id
HAVING COUNT(*) > 10 WITHIN 1 HOUR

// Flags: Rapid token refresh from non-corporate IPs for admin accounts
// Threshold: Adjust based on your baseline refresh patterns

Query 3: Admin SDK Scope Abuse — Third-Party App Behaviour

Detects third-party applications exercising Admin SDK or high-privilege scopes — a pattern consistent with compromised OAuth integrations performing unauthorized enumeration.

event_name IN ("list_users", "list_groups", "list_org_units")
AND actor.caller_type = "THIRD_PARTY_APP"
AND client_id NOT IN [approved_app_whitelist]

// Detects: Unauthorized apps using Admin SDK Directory API
// Scopes to monitor:
//   - https://www.googleapis.com/auth/admin.directory.user.readonly
//   - https://www.googleapis.com/auth/admin.directory.group.readonly
//   - https://www.googleapis.com/auth/gmail.readonly

Lessons Learned

For Investigators

• OAuth tokens are credentials. Treat refresh token theft with the same severity as password compromise. A stolen refresh token provides persistent, MFA-bypassing access to every resource the original consent grant authorized.
• Third-party app consent is a lateral movement vector. When investigating a compromised identity, enumerate every third-party app the user has authorized. Each consent grant is a potential persistence mechanism and a bridge to the vendor's infrastructure.
• Token refresh logs are the new authentication logs. Standard sign-in logs will show nothing abnormal. The attack signal lives in token refresh patterns: unusual IPs, unusual frequency, unusual client IDs refreshing tokens for accounts they should not be associated with.
• Aggregation attacks bypass data classification. Individual metadata fields classified as "non-sensitive" can be combined to reconstruct sensitive values. Investigate what was accessed in aggregate, not just individual file classifications.
• C2 domains mimic legitimate services. The exfiltration endpoint (api-update-verification[.]com) was designed to blend with legitimate API traffic. DNS and proxy log analysis must look beyond simple blocklist matching.

For Security Engineers

• Implement OAuth application whitelisting. Do not allow users to grant consent to arbitrary third-party applications. Use Google Workspace Admin > Security > API Controls to restrict which apps can access organizational data.
• Deploy token binding or continuous access evaluation (CAE). Where supported, enable Conditional Access policies that force re-evaluation of trust signals on every token refresh — not just initial authentication.
• Monitor and alert on token refresh anomalies. Build detection rules that correlate token refresh events with expected client IDs, IP ranges, and geographic locations. Any mismatch should trigger an investigation.
• Segment secrets from identity-accessible surfaces. Production secrets should never be accessible through the same identity plane that serves email and documents. Use dedicated secret management infrastructure (HSMs, Vault, KMS) with separate authentication chains.
• Audit third-party vendor OAuth integrations quarterly. Maintain an inventory of every OAuth consent grant in your organization. Review scopes, assess vendor risk, and revoke grants for applications no longer in active use.

CISO Checklist

• OAuth Application Whitelisting: Restrict third-party OAuth consent to pre-approved applications only. Implement Google Workspace API Controls to enforce organizational policy on which apps can access user data. Block new consent grants by default.
• Token Inventory & Revocation: Conduct an immediate audit of all active OAuth tokens in your Google Workspace tenant. Identify and revoke tokens associated with the compromised Context.ai Client ID. Establish a recurring token review cadence (minimum quarterly).
• Secret Isolation: Ensure production secrets, API keys, and KMS configurations are not stored in or accessible through Google Workspace surfaces (Gmail, Drive, Docs). Migrate to dedicated secret management infrastructure with separate authentication chains.
• Third-Party Risk Assessment: Review all OAuth-integrated vendors for security posture. Request SOC 2 Type II reports, penetration test results, and incident response plans. Evaluate whether each vendor's access scopes are appropriately minimized.
• MFA Hardening (FIDO2): Transition from push-based MFA to phishing-resistant FIDO2/WebAuthn tokens for all privileged accounts. Note: FIDO2 does not prevent OAuth token reuse attacks — but it eliminates the consent phishing vector that created the initial grants.
• Identity Threat Detection & Response (ITDR): Deploy ITDR capabilities that monitor the identity layer independently of endpoint and network detection. Focus on OAuth-specific signals: anomalous token refresh patterns, new consent grants, scope escalation, and cross-tenant token usage.

Mjolnir Security — Identity Security & Incident Response