Key Takeaways
- Vercel suffered a credential‑theft incident that originated from a compromised Context.ai employee’s workstation, not from Vercel’s own infrastructure.
- The attacker leveraged an OAuth token stolen from the employee’s Google Workspace account to enumerate Vercel environments and access non‑sensitive environment variables.
- Although Vercel states that customer data is encrypted at rest, the exposure of variables and secrets still poses a risk to affected customers.
- Both Vercel and Context.ai blame each other for overly permissive integrations, highlighting the danger of excessive privileges in SaaS‑to‑SaaS connections.
- The threat actor ShinyHunters claimed responsibility and is attempting to sell the stolen data, though analysts suspect the claim may be fabricated to boost notoriety.
- Vercel advised impacted customers to rotate credentials, review activity logs, and treat any exposed variables as compromised until proven otherwise.
- Ongoing forensic investigations are being conducted with CrowdStrike and Mandiant to determine the full scope and improve defenses against similar supply‑chain‑style attacks.
Overview of the Incident
Vercel disclosed in a security bulletin that attackers gained access to some of its internal systems by moving laterally through compromised third‑party services. The breach did not start within Vercel’s own environment; instead, it began when an employee of Context.ai, a provider of AI‑powered office tools, had their computer infected with the Lumma Stealer malware in February. The infection occurred after the employee searched for Roblox game exploits, a common lure for infostealer campaigns. Once the malware harvested credentials, it gave the attacker footholds into Context.ai’s AWS environment and, crucially, OAuth tokens linked to various user accounts—including a Google Workspace account belonging to a Vercel employee.
How the Attacker Gained Vercel Access
Using the stolen OAuth token, the attacker was able to takeover the Vercel employee’s Google Workspace account. This token granted the attacker the same privileges the employee had within Google Workspace, which Vercel had integrated via Context.ai’s Office Suite application. Because the Vercel employee had granted Context.ai full access to their Google Workspace account, the attacker inherited those permissions. From there, the attacker enumerated Vercel’s internal environments, locating environment variables that were not marked as sensitive. Although Vercel encrypts customer‑stored data at rest, the exposed variables—such as API keys, configuration strings, or other secrets—could be leveraged to further pivot or to impersonate services.
Vercel’s Response and Customer Guidance
Vercel stated that only a limited number of customers were impacted and that those affected were immediately instructed to rotate any potentially compromised credentials. The company published indicators of compromise (IOCs) and urged customers to review activity logs, inspect any variables that might contain secrets, and rotate them as a precaution. Vercel declined to disclose precisely which internal systems were accessed or the exact mechanics of how the attacker moved from the stolen token to customer‑level data, citing an ongoing investigation. However, the company emphasized that its core customer data remains protected by encryption, and that the attacker’s primary gain was through variable enumeration rather than direct data exfiltration.
Context.ai’s Role and Counter‑Claims
Context.ai admitted that the breach of its AWS environment allowed the attacker to obtain OAuth tokens for some users, including the Vercel employee’s Google Workspace token. The company argued that Vercel was not a direct customer of Context.ai, but that the Vercel employee had voluntarily installed Context.ai’s Office Suite and granted it broad permissions. Context.ai contended that the excessive permission scope granted by the Vercel employee facilitated the attacker’s lateral movement. In turn, Vercel implied that Context.ai’s security posture—particularly its handling of employee workstations and token management—allowed the initial compromise to occur. Both parties are conducting separate but coordinated investigations, assisted by CrowdStrike and Mandiant, to determine the exact chain of events.
Threat Actor Claims and Analyst Skepticism
A group identifying itself as ShinyHunters posted on Telegram claiming responsibility for the attack and offering to sell the purportedly stolen data, which they allege includes access keys, source code, and databases. Austin Larsen, a principal threat analyst at Google Threat Intelligence, warned on LinkedIn that the ShinyHunters claim is likely an attempt to piggyback on a well‑known reputation to inflate the attackers’ notoriety. Regardless of the true identity of the perpetrators, Larsen stressed that the exposure risk is genuine and that organizations should treat the incident as a credible threat until proven otherwise.
Broader Implications for SaaS Integrations
The incident underscores the risks inherent in highly interconnected cloud ecosystems where SaaS applications exchange OAuth tokens and other authentication mechanisms. When employees grant third‑party apps overly permissive access—such as “full access” to Google Workspace—they expand the attack surface dramatically. A compromise in one vendor can quickly cascade to partners, even if there is no direct contractual relationship. Security leaders are advised to adopt the principle of least privilege for all integrations, regularly review and revoke unnecessary token grants, and monitor for anomalous OAuth usage patterns. Additionally, employing strict endpoint protection, such as anti‑malware solutions capable of detecting Lumma Stealer and similar infostealers, can reduce the likelihood that an employee workstation becomes the initial foothold.
Lessons for Credential and Secret Management
Vercel’s guidance to rotate credentials and treat exposed variables as compromised highlights a fundamental best practice: secrets stored in environment variables should be rotated regularly and treated as potentially exposed whenever a breach of the surrounding infrastructure is suspected. Organizations should also consider using secret management platforms that provide automated rotation, access logging, and fine‑grained policy enforcement. In this case, the attacker did not need to break encryption; they merely harvested variables that were intended for internal use. By classifying any variable that could affect service authentication or configuration as sensitive, companies can apply stronger protections—such as encryption at rest, restricted IAM roles, and immediate alerting on anomalous reads.
Continuing Investigation and Future Defenses
Both Vercel and Context.ai affirmed that their investigations, conducted with the assistance of CrowdStrike and Mandiant, remain active. The goal is to map the attacker’s full trajectory, identify any additional systems that may have been touched, and harden defenses against similar supply‑chain‑style attacks. The episode serves as a reminder that even companies with strong encryption and robust internal controls can be undermined by the weakest link in their extended ecosystem—often an employee’s personal device or an overly permissive third‑party integration. Moving forward, a combination of rigorous endpoint security, zero‑trust network principles, and continuous monitoring of OAuth and API usage will be essential to mitigate the risk of credential theft cascading through interconnected SaaS platforms.