The Vercel Breach: OAuth Supply Chain Attack Exposes the Hidden Risk in Platform Environment Variables

Key Takeaways

• A compromised third-party OAuth application (Context.ai) granted attackers persistent, password-independent access to Vercel's internal systems.
• Vercel's default environment variable model left non-sensitive credentials unencrypted at rest, exposing customer secrets at platform scale.
• The attack had a dwell time of approximately 22 months, highlighting the difficulty of detecting OAuth-based lateral movement.
• The incident is part of a broader 2026 trend targeting developer credentials across CI/CD, package registries, and deployment platforms (e.g., LiteLLM, Axios).
• Effective defense requires treating OAuth applications as third-party vendors and migrating to dedicated secret managers.

Affected Systems

• Vercel platform
• Google Workspace
• Customer downstream services (AWS, GCP, Azure, Stripe, OpenAI, etc.)

Vulnerabilities (CVEs)

• CVE-2026-33634

Attack Chain

The attacker compromised Context.ai's Google Workspace OAuth application to gain initial access. Using this persistent OAuth token, they pivoted to a Vercel employee's Google Workspace account, bypassing traditional MFA and password controls. From there, they moved laterally into Vercel's internal systems and enumerated customer project environment variables. Because Vercel's default configuration stored non-sensitive variables unencrypted at rest, the attacker successfully exposed downstream customer credentials, leading to potential unauthorized access in connected cloud and SaaS environments.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No

The article provides conceptual detection logic and specific log fields to query in SIEM platforms (AWS CloudTrail, GCP Audit Logs, Azure Activity Logs, Google Workspace Audit Logs) but does not provide ready-to-use rule files.

Detection Engineering Assessment

EDR Visibility: Low — The attack primarily occurred in cloud control planes (Google Workspace, Vercel internal APIs, SaaS platforms) rather than on traditional endpoints where EDR is deployed. Network Visibility: Medium — Network logs may capture anomalous API calls to downstream services (e.g., AWS, Stripe) from unexpected IP addresses, but the initial lateral movement was within trusted cloud provider networks. Detection Difficulty: Hard — OAuth token abuse blends in with legitimate application traffic, bypasses MFA, and often lacks sufficient audit logging retention to trace back to the initial compromise.

Required Log Sources

• Google Workspace Audit Logs
• AWS CloudTrail
• GCP Audit Logs
• Azure Activity Logs
• Vercel Team Audit Logs
• SaaS API Logs (Stripe, OpenAI, etc.)

Hunting Hypotheses

Hypothesis	Telemetry	ATT&CK Stage	FP Risk
Anomalous OAuth application authorization or token usage from unexpected IP ranges indicates potential token theft or application compromise.	Google Workspace Audit Logs	Initial Access	Medium
Unusual volume of environment variable read or list API calls from a user account rather than a service account indicates potential internal reconnaissance.	Vercel Audit Logs	Discovery	Low
API calls to cloud providers (AWS, GCP, Azure) using Vercel-stored credentials originating from non-Vercel IP addresses indicates downstream credential abuse.	CloudTrail / Cloud Audit Logs	Lateral Movement	Low

Control Gaps

• Lack of default encryption at rest for all environment variables
• Insufficient OAuth application third-party risk management
• Inadequate detection of anomalous OAuth token usage
• Long-lived credentials stored in platform environment variables instead of dedicated secret managers

Key Behavioral Indicators

• OAuth Client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
• Unsolicited leaked-credential notifications from third-party providers (OpenAI, GitHub, etc.)
• API calls from unexpected user agents (python-requests, curl, Go-http-client) using platform-stored keys

False Positive Assessment

• Medium. Hunting for anomalous API usage or OAuth token refreshes may flag legitimate administrative actions, new integrations, or developer testing from new IP addresses.

Recommendations

Immediate Mitigation

• Rotate all Vercel environment variables not marked as sensitive.
• Redeploy all environments after credential rotation to invalidate old deployments.
• Enable the sensitive flag on all environment variables containing credentials.
• Revoke access for any unused OAuth applications in Google Workspace/Entra.

Infrastructure Hardening

• Migrate secrets to a dedicated secrets manager (Vault, AWS Secrets Manager, Doppler) and inject at runtime.
• Implement OIDC-based authentication for CI/CD and deployment pipelines.
• Establish automated credential rotation schedules (30-90 days).

User Protection

• Monitor identity provider logs for anomalous SSO/SAML authentication events.
• Review Google Workspace audit logs for bulk email search queries related to credentials.

Security Awareness

• Treat OAuth grants as third-party vendor relationships requiring security review.
• Treat unsolicited leaked-credential notifications from providers as high-priority early-warning signals.

MITRE ATT&CK Mapping

• T1199 - Trusted Relationship
• T1550.001 - Application Access Token
• T1078 - Valid Accounts
• T1087 - Account Discovery
• T1552.001 - Unsecured Credentials: Credentials in Files
• T1078.004 - Valid Accounts: Cloud Accounts
• T1213 - Data from Information Repositories

Additional IOCs

• Command Lines:
  • Purpose: List environment variables across Vercel projects to audit configuration | Tools: vercel CLI | Stage: Defense/Audit | vercel env ls --environment