Issuu

Threat Analysis Report July 31, 2026

Vercel OAuth Supply Chain Compromise An Analysis of OAuth Abuse Sneha Lama | Aarav Jain | Razan Mukdadi

Table of Contents 1. Executive Summary..........................................................................................2 2. Threat Overview..............................................................................................3 3.1 Incident Timeline........................................................................................4 3.2 Attack Chain Overview................................................................................7 3.3 Attack Stage Breakdown...............................................................................8 Stage 1: Context.ai Employee Compromise.........................................................8 Stage 2: Context.ai Infrastructure and OAuth Token Compromise.............................9 Stage 3: Vercel Employee Identity Compromise...................................................9 Stage 4: Internal Pivot into Vercel.....................................................................9 Stage 5: Environment Variable Access and Customer Exposure................................9 5. Indicators of Compromise (IOCs)......................................................................10 6. Impact Assessment..........................................................................................11 7. Recommendations..........................................................................................13 8. Key Takeaways..............................................................................................14 9. References.....................................................................................................16

Threat Analysis Report July 31, 2026

1. Executive Summary In April 2026, Vercel disclosed a security incident involving unauthorized access to certain internal systems after a compromise connected to Context.ai, a third party AI tool used by a Vercel employee. The attacker used access from the Context.ai compromise to take over the employee’s Vercel Google Workspace account, then moved into a Vercel environment and accessed environment variables that had not been marked as sensitive [1]. Vercel stated that a limited subset of customers was impacted and that affected customers were contacted directly with guidance to rotate credentials [1]. The incident is important because it shows how a trusted third party SaaS or AI integration can become an attack path into a larger organization. Public reporting linked the earlier Context.ai compromise to Lumma Stealer activity and later OAuth token exposure, which allowed the attacker to abuse delegated access instead of relying on a traditional password-based login path [2]-[4]. This made the breach less about one weak password and more about the risk created by OAuth trust relationships, broad application permissions, and long lived access tokens. From a blue team perspective, the Vercel incident highlights the need for stronger OAuth governance, better visibility into third party application access, and stricter handling of deployment secrets. Environment variables can contain API keys, database credentials, signing secrets, and cloud access tokens, so exposure of these values can create downstream risk beyond the original platform [1], [3]. Organizations using Vercel or similar cloud deployment platforms should review third-party OAuth grants, rotate exposed or potentially exposed credentials, mark secrets as sensitive, monitor unusual access activity, and treat AI SaaS integrations as part of their broader supply chain risk management process [1], [2], [5].

Threat Analysis Report July 31, 2026

2. Threat Overview The Vercel incident is best characterized as a SaaS supply chain attack carried out through identity compromise rather than through a vulnerability in Vercel's own software. According to security reporting, the attacker did not exploit a flaw in Vercel's code or infrastructure and instead authenticated into the environment using a valid OAuth token that a Vercel employee had previously granted to a third-party AI tool [3], [7]. The activity combined several threat patterns that increasingly appear together: an information-stealing malware infection at the third party, abuse of delegated OAuth access to move between connected systems, and the subsequent theft and attempted sale of stolen data [4], [5], [7]. In its overall shape, the incident reflects a supply chain attack in which a trusted vendor relationship, rather than a direct attack on the target, provided the route into the affected organization [2], [7]. The compromise affected systems across three layers. At the third-party layer, Context.ai's environment was breached and OAuth tokens it held for its users were exposed [4], [7]. At the identity layer, a Vercel employee's corporate Google Workspace account was reached through the stolen token, followed by the associated Vercel account [4], [6]. At the platform layer, the attacker accessed internal Vercel systems and ultimately customer environment variables [1], [7]. The exposed data consisted primarily of environment variables that customers had not marked as sensitive, which may contain API keys, tokens, database credentials, and similar values [1], [3]. Vercel reported that environment variables marked as sensitive were not accessed, that its published npm packages were not compromised, and that its open-source projects were not affected [1], [4]. The severity of the incident is assessed as high. This rating reflects the confirmed compromise of non-sensitive customer environment variables, which may have contained production API keys, tokens, database credentials, signing keys, or other secrets and unverified claim that allegedly stolen Vercel data was advertised on BreachForums for $2 million. The forum poster claimed an affiliation with ShinyHunters, but neither the claimed data nor the actor’s affiliation has been independently confirmed, and Vercel has not attributed the incident to ShinyHunters [1], [3], [5]. Two factors limit the impact without removing it. Vercel stated that the affected customer population was limited and that those customers were contacted directly, and the platform's services reportedly remained operational throughout the incident [1], [4]. The primary consequence is therefore loss of confidentiality and exposure of credentials rather than 3

Threat Analysis Report July 31, 2026 disruption of service, although exposed production credentials present a continuing risk until they are rotated. The main risk introduced by the incident is cascading downstream compromise. The exposed API keys and database credentials are themselves valid means of access to other systems, so the breach can serve as a starting point for further intrusions into affected customer environments [7]. Use of a stolen OAuth token may not require a new interactive login or MFA challenge because the authorization was previously granted. Detection therefore depends heavily on OAuth, API, application-consent, and SaaS activity logs rather than traditional failed-login telemetry. [7]. A third risk relates to unsanctioned tools and over-scoped access, since the connection that enabled the attack was a broad OAuth grant to a third-party AI tool made without security oversight [7]. A further factor is the reliance on long-lived static secrets, which remain valid until manually rotated and which required affected organizations to carry out emergency credential rotation once the breach was disclosed [6]. Taken together, the incident demonstrates how a compromise at a third-party provider can extend into a downstream organization through delegated identity access. Its significance lies less in any single exposed credential than in the trust relationships and standing access that allowed one compromised vendor to reach into a major platform and, potentially, its customers [2], [4], [7].

3. Attack Timeline and Attack Chain 3.1 Incident Timeline The Vercel incident developed over several stages beginning with the compromise of a third party AI provider and later expanding into Vercel’s internal environment. Public reporting indicates that the activity began in February 2026 and remained active through March and April before Vercel disclosed the incident on April 19, 2026 [1], [2], [3]. The timeline below separates confirmed events from reported findings where the complete forensic details have not been publicly released.

Date or period February 2026

Event A Context.ai employee 4

Verification status Reported by multiple security

Threat Analysis Report July 31, 2026 endpoint was reportedly infected with Lumma Stealer. The malware collected corporate credentials and

sources

authentication data that later became relevant to the wider compromise [2], [3], [4]. An unauthorized actor gained access to Context.ai’s AWS environment. Context.ai later March 2026

determined that OAuth tokens belonging to some

Confirmed through Context.ai reporting

users were also likely compromised [2], [4]. The attacker used compromised OAuth access connected to a Vercel March 2026

employee to access the employee’s Vercel Google

Confirmed

Workspace account and associated Vercel account [1], [2], [4]. The attacker pivoted into a Vercel environment and Following the account compromise

moved through internal systems to enumerate and

Confirmed by Vercel

decrypt environment variables that had not been marked as sensitive [1].

April 19, 2026

Vercel publicly disclosed the incident and released an 5

Confirmed

Threat Analysis Report July 31, 2026 OAuth application identifier to support investigation by Google Workspace administrators and affected organizations [1]. Vercel reported that its review with GitHub, Microsoft, npm, and Socket found no evidence April 20, 2026

that Vercel-published npm

Confirmed

packages had been compromised or modified [1], [4]. Vercel expanded its investigation and identified a small number of additional By April 23, 2026

affected accounts. It also identified separate customer

Confirmed

account compromises that did not appear to have originated from the April incident [1]. Vercel moved future bulletin updates to an ad hoc schedule April 24, 2026

while continuing its

Confirmed

investigation and remediation work [1].

The sequence shows that the incident did not begin with a direct compromise of Vercel’s public infrastructure. Instead the attacker moved through a chain of trusted access beginning with Context.ai then crossing into a Vercel employee’s enterprise identity and finally reaching internal 6

Threat Analysis Report July 31, 2026 Vercel resources [1], [2]. Vercel described the affected customer population as limited and stated that identified customers were contacted directly. The exact number of affected customers and the complete scope of the attacker’s internal access have not been publicly disclosed [1]. 3.2 Attack Chain Overview The Vercel incident developed through a multi-stage trust chain rather than a direct compromise of Vercel’s public-facing infrastructure. The initial access began with a reported Lumma Stealer infection affecting a Context.ai employee. That compromise later enabled unauthorized access to Context.ai’s environment and the likely exposure of OAuth tokens belonging to users of the service [2], [3], [4]. One of the affected OAuth relationships was connected to a Vercel employee who had authorized Context.ai using a corporate Google Workspace account. The attacker used that trusted access to take over the employee’s Workspace account and reach the associated Vercel account. From there the attacker pivoted into a Vercel environment and accessed environment variables that had not been marked as sensitive [1], [2], [4]. The overall attack path can be summarized as follows: i.

Context.ai employee endpoint compromised

ii.

Corporate credentials and authentication data exposed

iii.

Unauthorized access to Context.ai infrastructure

iv.

OAuth tokens belonging to Context.ai users compromised

Vercel employee's Google Workspace account accessed

vi.

Associated Vercel account compromised

vii.

Attacker pivoted into a Vercel environment

viii.

Non sensitive environment variables enumerated and decrypted

Threat Analysis Report July 31, 2026

Figure 1. Attack Path Vercel Compromise

The incident shows how an OAuth integration can become an identity attack path when a third party provider is compromised. Context.ai’s access did not remain isolated to its own systems because the application held delegated permissions inside the Vercel employee’s corporate identity environment. Once the attacker obtained control of that trusted relationship they were able to move across systems without first compromising the employee’s password through a traditional login attack [1], [5]. The public record does not explain every internal action used after the employee account was compromised. Vercel confirmed that the attacker moved through its systems and accessed non-sensitive environment variables but did not disclose the complete lateral movement sequence or every internal resource involved [1]. For that reason the attack chain above includes only the stages supported by official disclosures and consistent third party reporting. 3.3 Attack Stage Breakdown Stage 1: Context.ai Employee Compromise The attack began with the reported compromise of a Context.ai employee endpoint in February 2026. Security reporting linked the initial infection to Lumma Stealer, an informationstealing malware capable of collecting stored credentials, session data, and other authentication material from an infected system [2], [3], [4]. This endpoint compromise provided the attacker with a starting point for accessing Context.ai’s corporate environment. 8

Threat Analysis Report July 31, 2026 Stage 2: Context.ai Infrastructure and OAuth Token Compromise In March 2026, Context.ai identified unauthorized access to its AWS environment. Further investigation indicated that OAuth tokens associated with some users of the service were also likely compromised [2], [4]. Because OAuth tokens can provide delegated access without requiring a user’s password for each session, the stolen tokens created a path into connected customer environments. Stage 3: Vercel Employee Identity Compromise At least one Vercel employee had connected Context.ai to a corporate Google Workspace account and granted broad OAuth permissions. The attacker used compromised OAuth access to reach the employee’s Workspace account and then the associated Vercel account [1], [2], [4]. This allowed the attacker to operate through an existing trusted identity rather than beginning with a direct attack against Vercel’s external infrastructure. Stage 4: Internal Pivot into Vercel After gaining access to the employee’s Vercel account, the attacker moved into a Vercel environment and continued through internal systems [1]. Vercel has not publicly disclosed the exact sequence of internal actions used during this stage, so the available evidence does not support a more detailed reconstruction of the lateral movement path. The confirmed information shows that the compromised identity provided a bridge from the third-party OAuth relationship into Vercel resources [1], [5]. Stage 5: Environment Variable Access and Customer Exposure The attacker ultimately enumerated and decrypted environment variables that customers had not marked as sensitive [1]. These variables may contain API keys, tokens, database credentials, signing secrets, and other values that provide access to connected services. Vercel stated that the affected customer population was limited and that customers identified during the investigation were contacted directly [1]. Vercel also reported no evidence that environment variables marked as sensitive were accessed and confirmed that Vercel-published npm packages were not compromised [1], [4]. 9

Threat Analysis Report July 31, 2026 The scope of the exposure was also influenced by how the environment variables were configured. Vercel’s sensitive-variable feature prevents protected values from being read after creation, but the variables accessed during the incident had not been marked as sensitive [1]. Secondary reporting characterized the sensitive designation as an opt in configuration rather than protection automatically applied to every environment variable [8]. This configuration issue did not provide the attacker’s initial access, but it increased the impact after the attacker reached Vercel’s environment. The incident demonstrates how compromise at a third-party provider can extend into a downstream organization through delegated identity access. Each stage depended on an existing trust relationship, beginning with the Context.ai employee environment and ending with access to customer-linked credentials stored within Vercel [1], [2], [5].

4. MITRE ATT&CK Mapping The attack path maps to MITRE ATT&CK techniques related to OAuth token abuse and cloud identity compromise. The mapping below focuses only on behaviors supported by the reported incident details. Technique T1528

Name Steal Application Access Token

T1550.001

Use Alternate Authentication Material: Application Access Token

T1078.004

Valid Accounts: Cloud Accounts

Application to incident OAuth tokens held by the compromised third party were reportedly exposed. The stolen OAuth authorization was used to access downstream cloud resources without repeating the normal authentication process. The attacker operated through the employee’s Google Workspace and Vercel cloud identities.

5. Indicators of Compromise (IOCs) The confirmed indicator of compromise associated with the Vercel OAuth supply chain compromise is the Google Workspace OAuth application client ID: 10

Threat Analysis Report July 31, 2026 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com [1] The incident involved a compromised third-party AI tool, Context.ai, which was previously granted broad Google Workspace permissions by a Vercel employee. Context.ai is the third-party AI tool involved in the incident, not the IOC itself. A Vercel employee signed up for Context.ai using their Vercel enterprise Google Workspace account. They granted “Allow All” OAuth permissions, a scope that is both easy to click and difficult to audit after the fact. After Context.ai was compromised, the attacker was able to use the OAuth token to access the employee’s Google Workspace account without needing the employee’s password or MFA challenge. [6] Security teams should monitor for activity that indicates abuse of OAuth permissions, suspicious Google Workspace access, and unusual Vercel activity. Since this incident originated from a compromised third-party AI tool and an abused OAuth grant, [6] detection should focus on both identity activity and developer platform activity. Organizations should first review Google Workspace OAuth activity for the known suspicious OAuth client ID. In addition to the confirmed IOC, defenders should monitor for newly authorized third-party OAuth applications, applications granted broad Google Workspace permissions, OAuth activity from unusual IP addresses or locations, and OAuth-based access that does not match the user’s normal behavior. As of Vercel’s April 24, 2026 bulletin update, the OAuth application client ID below was the only publicly released, Vercel-confirmed IOC. Additional internal indicators may exist but have not been publicly disclosed. This means defenders should focus their investigation on Google Workspace OAuth activity, authorized applications, browser extension usage, and account access logs. IOC Type Google Workspace OAuth Application Client ID

Indicator 11067145987130f1spbu0hptbs60cb4vsmv79 i7bbvqj.apps.googleuserconte nt.com

6. Impact Assessment Impact on systems

Description OAuth client ID associated with the compromised Context.ai integration.

Relevance This is the confirmed IOC defenders can search for in Google Workspace OAuth activity.

Threat Analysis Report July 31, 2026 The most direct technical impact was the exposure of customer environment variables stored within Vercel, which may include API keys, tokens, database credentials, and signing secrets [1], [3]. Because these values are functional credentials rather than static data, their exposure effectively hands an attacker working keys to any system they authenticate against. The risk is not limited to Vercel itself, since a single exposed key can grant access to databases, cloud accounts, payment processors, or other connected services that sit outside the Vercel environment entirely [3], [7]. Vercel reported that environment variables marked as sensitive were not accessed and that its published npm packages and open-source projects were not affected, which limited the technical blast radius but did not remove the exposure of the variables that were reached [1], [4]. Impact on users End users of affected customer applications were not the direct target, but they inherit downstream risk. If a stolen database credential or API key permits access to a production system, the personal or account data held in that system becomes exposed by extension, even though users took no action and may be unaware of any connection to the incident [3], [7]. This indirect exposure is characteristic of supply chain attacks, where harm propagates through trust relationships several steps removed from the original victim. Impact on organizations For affected customer organizations, the principal impact is the operational and security burden of responding to compromised production credentials. Once the breach was disclosed, affected organizations had to identify and rotate every credential that may have been exposed, an effort that is time-consuming and disruptive when secrets are long-lived and spread across many systems [6]. Organizations also face reputational and trust consequences, both for Vercel as the platform where the exposure occurred and for Context.ai as the third party whose compromise initiated the chain [2], [7]. The public listing of allegedly stolen data on BreachForums, reported to include customer API keys and source code offered for $2 million, raises the prospect of further attacks against affected organizations. The forum advertisement and the identity of the 12

Threat Analysis Report July 31, 2026 seller remain unverified, and Vercel has not publicly attributed the incident to a specific threat actor [1], [3], [5]. Why the incident is harmful The incident is harmful for reasons that go beyond the immediate data exposure. First, the attack bypassed conventional defenses entirely, because a valid OAuth token is accepted by downstream systems without triggering password or multi-factor prompts, which means the intrusion produced few of the signals that normally allow early detection [7]. Second, the harm cascades through trust relationships, so a single compromised vendor reached a major platform and, through it, potentially many customer environments [2], [7]. Third, the reliance on longlived static secrets meant that exposed credentials remained valid and exploitable until manually rotated, extending the window of risk well beyond the date of the original compromise [6]. Together these factors make the incident a representative example of a class of attack that is difficult to detect, broad in reach, and slow to remediate.

7. Recommendations Immediate actions Organizations that use Vercel, Context.ai, or connected services should treat the incident as an active credential exposure and respond accordingly. Affected customers identified by Vercel were contacted directly and should follow the rotation guidance provided in the official bulletin [1]. As a priority, organizations should rotate any API keys, tokens, database credentials, and other secrets associated with Vercel-backed workflows, treating exposed values as compromised until replaced [4], [6]. Security teams should also search their Google Workspace and OAuth application inventory for the Context.ai integration and revoke it where present, using the reported client identifier “11067145987130f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com” as a search indicator [7]. Finally, teams should review access logs for the affected systems and look for access from

Threat Analysis Report July 31, 2026 unfamiliar infrastructure or unusual locations, which can indicate that a token has been used by an attacker [7]. Long-term recommendations Reducing the likelihood and impact of similar incidents requires structural changes rather than one-time fixes. Organizations should establish ongoing governance of third-party OAuth grants, including a regular inventory of connected applications, removal of unused or overscoped integrations, and review of any tool connected without security oversight [6], [7]. Reducing the lifetime of secrets is equally important, since short-lived or just-in-time credentials limit how long a stolen value remains useful and reduce the burden of emergency rotation during an incident [6]. Organizations should also separate sensitive from non-sensitive secrets explicitly so that the most privileged values receive stronger handling, a distinction that materially limited the impact of this incident for customers who had applied it [1], [3]. More broadly, security teams should extend identity and behavioral monitoring to third-party integrations and AI tools, establishing a baseline of normal activity for each so that anomalous use of a token can be detected rather than discovered only after exfiltration [7]. Treating non-human and AI-agent identities with the same rigor as human and service accounts, including issuance, rotation, and revocation, addresses the underlying trend that made this attack possible [6], [7].

8. Key Takeaways This incident has shown that third party AI tools and browser extensions can also become a supply chain entry point when they are trusted by employees and connected to corporate accounts. [5] One important lesson is that organizations need stronger visibility into OAuth integrations. When employees authorize third-party applications, those applications may receive long-lived access to corporate resources. This can create a hidden path into the organization if the third-party provider is later compromised. Security teams should treat OAuth applications like external vendors by reviewing permissions, enforcing least privilege, and removing unnecessary integrations.

Threat Analysis Report July 31, 2026 The incident also revealed the growing risk of shadow AI. Employees may adopt AI tools to improve productivity, but those tools can request access to sensitive data such as Google Workspace, Drive files, or internal data. Organizations should not only block risky tools, but also create clear approval processes for safe AI use so employees are not forced to rely on unmanaged applications.

Threat Analysis Report July 31, 2026

9. References [1] Vercel Security Team, “Vercel April 2026 security incident,” Vercel Knowledge Base, updated Apr. 24, 2026. Available: Vercel April 2026 security incident | Vercel Knowledge Base [2] Cloud Security Alliance AI Safety Initiative, “AI SaaS as Enterprise Attack Vector: The Vercel-Context.ai Breach,” Cloud Security Alliance, Apr. 20, 2026. Available: AI SaaS as Enterprise Attack Vector: The Vercel–Context.ai Breach – Lab Space [3] P. Girnus, “The Vercel Breach: OAuth Supply Chain Attack Exposes the Hidden Risk in Platform Environment Variables,” Trend Micro, Apr. 20, 2026. Available: The Vercel Breach: OAuth Supply Chain Attack Exposes the Hidden Risk in Platform Environment Variables | Trend Micro (US) [4] R. Lakshmanan, “Vercel Breach Tied to Context AI Hack Exposes Limited Customer Credentials,” The Hacker News, Apr. 20, 2026. Available: Vercel Breach Tied to Context AI Hack Exposes Limited Customer Credentials [5] M. S. T. Bustan and N. Zadok, “Supply Chain Attack Hits Vercel: User Data is Being Sold on BreachForums for $2M,” OX Security, Apr. 20, 2026. Available: Supply Chain Attack Hits Vercel: User Data is Being Sold on BreachForums For $2M | OX Security [6] R. Angel, “The Vercel Breach and the Case for Ephemeral Secrets,” Akeyless, Apr. 21, 2026. Available: The Vercel Breach and the Case for Ephemeral Secrets [7] Obsidian Security, “The Vercel Breach and the Growing SaaS Supply Chain Challenge,” Obsidian Security, Apr. 21, 2026. Available: The Vercel Breach and the Growing SaaS Supply Chain Challenge [8] Apidog, “7 API Security Lessons from Vercel's 2026 Breach,” Apidog Blog, Apr. 20, 2026. Available: 7 API Security Lessons from Vercel's 2026 Breach Threat Advisory created by The Cyber Florida Security Operations Center. Contributing Security Analysts: Sneha Lama, Aarav Jain, Razan Mukdadi To learn more about Cyber Florida visit: www.cyberflorida.org 16