DEV Community

Cover image for Vercel OAuth Compromise via Context.ai: Timeline, IOCs, and Remediation
CyberXYZ Security
CyberXYZ Security

Posted on • Originally published at cyberxyz.io

Vercel OAuth Compromise via Context.ai: Timeline, IOCs, and Remediation

On April 19, 2026, Vercel confirmed a security incident involving unauthorized access to their internal systems. The breach originated through a compromised third-party AI tool called Context.ai. An attacker exploited a Google Workspace OAuth vulnerability in Context.ai to gain access to a Vercel employee's Google account, then leveraged that foothold to penetrate Vercel's internal infrastructure.

Vercel described the attacker as "highly sophisticated based on their operational velocity and detailed understanding of Vercel's systems." The company engaged Mandiant, additional cybersecurity firms, industry partners, and law enforcement for investigation and remediation.

This isn't a traditional software vulnerability. There's no CVE to patch because no specific package is vulnerable. Instead, this is an infrastructure-level breach exploiting the trust chain between a third-party OAuth app, Google Workspace, and Vercel's internal systems, classified under MITRE ATT&CK T1199 (Trusted Relationship).

Why traditional scanners missed this: Package-level security tools (SCA, SAST, dependency scanners) look for known CVEs and malicious packages. Infrastructure breaches at platform providers don't produce CVEs. They produce compromised trust relationships — a different detection problem.

Timeline of Events

  • Prior to April 19, 2026 — Attacker compromised a Vercel employee's Google Workspace account through a prior breach at Context.ai, a third-party AI platform. The compromised OAuth app (T1528) provided the initial access vector into Vercel's environment.
  • April 19, 2026 at 11:04 AM PST — Vercel published the confirmed IOC (a malicious OAuth App ID) to assist the community with their own investigations.
  • April 19, 2026 at 6:01 PM PST — Vercel disclosed the origin of the attack (Context.ai compromise) and published full customer recommendations including environment variable rotation and deployment protection guidance.
  • April 19, 2026 — A threat actor claiming to be ShinyHunters posted alleged proof of the breach on Telegram, including employee data and internal dashboard screenshots, with a $2 million ransom demand. Real ShinyHunters members denied involvement to BleepingComputer.
  • April 20, 2026 — CyberXYZ ingested the incident as VENDOR-2026-0419-VERCEL and issued vendor breach alerts to platform users.

Indicator of Compromise (IOC)

Vercel published one confirmed IOC. Google Workspace administrators should immediately audit whether this OAuth application has been authorized in their organization.

Type Indicator
OAuth App ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

How to check for this IOC: Google Workspace admins can audit OAuth app usage in the Admin Console under Security → API Controls → Third-party app access. Search for the OAuth App ID above and revoke access if found.

What Was Compromised

According to Vercel's security bulletin:

  • Environment variables that were not marked as "sensitive" were enumerable by the attacker. Vercel confirmed that sensitive environment variables (those using their encryption feature) were not accessed
  • 580 employee records containing names, Vercel email addresses, account status, and activity timestamps
  • Internal systems including access to Linear (project management), source code, and database data were claimed by the threat actor
  • A limited subset of customer credentials were compromised. Vercel directly contacted all affected customers

Vercel stated: "If you have not been contacted, we do not have reason to believe that your Vercel credentials or personal data have been compromised."

Supply-Chain Risk Analysis

This breach is a textbook example of a trusted relationship attack. The attacker didn't target Vercel directly. They compromised a third-party AI tool (Context.ai) that had OAuth access to a Vercel employee's Google account. From there, they pivoted into Vercel's internal infrastructure.

This pattern is increasingly common: attackers identify the weakest link in the OAuth trust chain rather than attacking the primary target head-on. Every third-party app authorized in your Google Workspace or GitHub organization is a potential entry point.

Traditional SCA and vulnerability scanning tools cannot detect this class of threat because there is no vulnerable package to flag. The compromise exists entirely in the trust relationships between platforms.

Recommended Actions

Immediate (based on Vercel's guidance)

  1. Audit Google Workspace OAuth apps for the IOC above and revoke if found
  2. Review account activity logs in your Vercel dashboard for suspicious behavior
  3. Rotate environment variables containing secrets that were not marked as "sensitive" in Vercel
  4. Enable sensitive environment variable protection for all secrets going forward
  5. Investigate recent deployments for any anomalies or unauthorized changes

Short-Term (This Week)

  1. Enable Deployment Protection (minimum Standard level) on all projects
  2. Rotate Deployment Protection tokens if previously configured
  3. Audit all third-party OAuth apps authorized in your Google Workspace organization
  4. Review and remove access for any AI tools or third-party services that no longer need OAuth access

Long-Term Recommendations

  • Adopt fine-grained personal access tokens over broad OAuth grants where possible
  • Implement a formal third-party app approval process for Google Workspace and GitHub
  • Monitor for vendor and platform breaches using infrastructure-level threat detection
  • Maintain a vendor risk inventory per NIST SP 800-161r1 covering all CI/CD and deployment platform integrations

References

  1. Vercel Security Bulletin — Vercel April 2026 Security Incident
  2. BleepingComputer — Vercel confirms breach as hackers claim to be selling stolen data (April 19, 2026)
  3. MITRE ATT&CK — T1199 Trusted Relationship
  4. MITRE ATT&CK — T1528 Steal Application Access Token
  5. NIST SP 800-161r1 — Cybersecurity Supply Chain Risk Management

Originally published on CyberXYZ Security Research Blog.

Top comments (0)