Vercel disclosed a security incident on April 19, 2026 that began nowhere near its own infrastructure. The initial compromise was at Context.ai, a third-party AI tool that a single Vercel employee had connected to their corporate Google Workspace account.
The confirmed impact is narrower than the claims circulating around it, and the distinction matters. " It confirmed, in collaboration with GitHub, Microsoft, npm and Socket, that no npm packages published by Vercel were compromised. That last point deserves emphasis, because for a company at the centre of the JavaScript ecosystem the default assumption on disclosure day was package tampering. There was none.
KEY FACTS
- WhatAn attacker compromised a third-party AI tool, used the resulting OAuth access to take over a Vercel employee's corporate Google Workspace account, and pivoted into Vercel systems to enumerate and decrypt customer environment variables.
- WhoVercel, a cloud development and deployment platform. A limited subset of customers, plus additional accounts identified later. Exact counts were not published. Vercel describes the compromised OAuth app as "potentially affecting its hundreds of users across many organizations."
- HowCompromise of Context.ai, connected to a Vercel employee's Google Workspace account. Google OAuth client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Sources disagree on whether the grant originated from a web signup or a browser extension install.
- DataEnvironment variables not marked "Sensitive," which decrypt to plaintext. Vercel instructed customers to treat those values, "API keys, tokens, database credentials, signing keys, etc.," as potentially exposed.
- ActorNo formal technical attribution has been issued. Vercel assesses the attacker as "highly sophisticated" and is working with Google Mandiant. Hudson Rock names ShinyHunters; a GTIG analyst assessed the forum claimant as a likely imposter. These conflict.
- ImpactCustomer secrets held in non-sensitive environment variables must be treated as compromised and rotated. No npm package tampering. No confirmed loss of customer source code.
WHAT HAPPENED
The chain begins outside both companies. Hudson Rock uncovered that a Context.ai employee was compromised with Lumma Stealer in February 2026. " The infostealer harvested that employee's credentials, including Google Workspace logins along with Supabase, Datadog and Authkit keys. " Context.ai has published its own disclosure of a March 2026 incident involving unauthorized access to its AWS environment. It stated: "We also learned that the unauthorized actor appears to have used a compromised OAuth token to access Vercel's Google Workspace.
That is the pivot point, and it is where the reporting diverges. Vercel's bulletin frames the entry as an OAuth application compromise. Context.ai's account points to a web signup for the AI Office Suite. The Hacker News, characterising analysis by OX Security, reports that initial access began when the Vercel employee installed the Context.ai browser extension and signed into it with their enterprise Google account.
Hudson Rock adds a fourth thread: the infected Context.ai employee held Vercel access of their own, described as "a core member of the 'context-inc' Vercel team," with browser history showing direct visits to that team's environment-variables settings page. Whether that separate access played any role in the route into Vercel's internal systems is not established by any source. No source reconciles these accounts. This report treats the entry vector as disputed.
Additional details shared by Jaime Blasco, CTO of Nudge Security, identified a second Google OAuth client ID tied to a Chrome extension with Google Drive read access, and established that Google removed that extension from the Chrome Web Store on March 27, 2026. That was a platform enforcement action by Google, not a remediation step by Context.ai. ZERO|TOLERANCE notes separately that both client IDs share the same Google Cloud project number, an inference from the identifiers themselves rather than a published finding.
Vercel published its bulletin on April 19, 2026 at 11:04 AM PST, initially releasing an indicator of compromise so other organisations could check their own tenants for the same OAuth grant. At 6:01 PM PST it disclosed the origin of the attack and added customer recommendations. Further entries followed on April 20 at 10:59 AM and 5:32 PM PST, April 22 at 7:58 PM PST, and April 23 at 9:54 AM PST. The April 24 entry at 4:22 PM PST records "No updates published." The April 20 evening entry recorded the npm validation work and shipped product changes alongside new MFA guidance.
Separately, and on the day of disclosure, BleepingComputer reported that an individual posting under the ShinyHunters name offered to sell access keys, source code, database data, internal deployment access and API keys.
The actor posted a text file of 580 records containing names, Vercel email addresses, account status and activity timestamps, plus "a screenshot of what appears to be an internal Vercel Enterprise dashboard," and wrote: "This is just from Linear as proof, but the access I'm about to give you includes multiple employee accounts with access to several internal deployments, API keys (including some NPM tokens and some GitHub tokens)". Telegram messages referenced an alleged $2 million ransom demand.
BleepingComputer could not independently verify the authenticity of the materials, and reported that threat actors linked to recent attacks attributed to the ShinyHunters extortion gang denied involvement to the publication. None of these claims appear in Vercel's confirmed findings.
THE "NON-SENSITIVE" QUALIFIER
Vercel uses the term deliberately and it should be read as a storage classification rather than a risk assessment. " The distinction is not encrypted versus plaintext. It is whether the platform can decrypt the value back to plaintext in normal operation. Standard variables can be decrypted, which is why an attacker with sufficient reach could enumerate and read them. Variables marked "Sensitive" cannot be read back. Reporting that describes non-sensitive variables as stored unencrypted is wrong, and that error has appeared in coverage of this incident.
So "non-sensitive" describes how the value is stored, not what the value is. Vercel's own remediation instruction closes any ambiguity: customers were told to review and rotate environment variables not marked sensitive, because "those values (API keys, tokens, database credentials, signing keys, etc.) should be treated as potentially exposed." A production database credential stored in a standard environment variable is a production database credential.
A caution on the Sensitive tier, and a live example of why it is needed. " That statement does not appear in the current live bulletin.
That hedge is already hardening into a fact in the wild. A vendor post by Reco states that "environment variables explicitly flagged 'sensitive'... " An absence-of-evidence statement from a withdrawn revision has become a definitive all-clear inside a single document. Vercel has never stated whether Sensitive-tier variables were accessed. Customers who used that tier should not read any of this as clearance.
THREAT ACTOR
No formal attribution has been issued by Vercel, by a government CERT, or by Mandiant. " Rauch went further on X, supplying a competing explanation for that velocity: "We believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI. " That is an on-record claim from an affected CEO, and it is interpretive rather than forensic. Velocity is consistent with AI augmentation, with competent scripting, and with prior familiarity with the platform. No published evidence distinguishes among them.
Actor identity is contested. " BleepingComputer reported that threat actors linked to recent ShinyHunters-attributed attacks denied involvement. These positions conflict: one vendor names the group, one analyst doubts the claimant, and actors associated with the brand disclaim it. Hudson Rock's confidence rests on infection-database correlation, not on intrusion forensics at Vercel. ZERO|TOLERANCE treats this incident as unattributed.
WHAT WAS EXPOSED
Confirmed by Vercel:
- Environment variables not marked "Sensitive" belonging to a limited subset of customers, decrypted from recoverable storage.
- Per Vercel's own guidance, the contents should be assumed to include API keys, access tokens, database credentials and signing keys.
- A small number of additional accounts identified during the expanded investigation.
- A small number of customer accounts showing signs of compromise that appear separate from the April 2026 incident.
Explicitly ruled out by Vercel:
- npm packages published by Vercel. Confirmed with GitHub, Microsoft, npm and Socket, with no evidence of tampering.
Reported but not confirmed in the current bulletin:
- That environment variables marked "Sensitive" were not accessed. This rests on a superseded bulletin revision quoted by The Hacker News, phrased as "no evidence suggesting" rather than a finding. Do not treat the Sensitive tier as cleared.
Claimed by the forum actor and NOT confirmed by Vercel or verified by reporters:
- Source code, database contents, internal deployment access, GitHub and npm tokens.
- A file of 580 records containing names, corporate email addresses, account status and activity timestamps.
- Access to an internal Linear project management instance, and a $2 million demand referenced on Telegram.
TECHNICAL FAILURE CHAIN
The chain starts with a Context.ai employee installing game exploit tooling on a machine holding corporate credentials. An infostealer infection on a device with access to a SaaS provider's production identity is a total compromise of every tenant that provider can reach.
A Vercel employee connected an AI tool to their corporate Google Workspace account. Nothing about that action was anomalous to the employee, and nothing about it appears to have been reviewed. Default Google Workspace configuration permits users to authorise third-party applications unless an administrator applies app access control.
Context.ai's disclosure states the employee "granted 'Allow All' permissions." The specific Google OAuth scopes were never published, so the exact authorisation surface remains unverified. What is not in dispute is that the grant was sufficient for account takeover.
This is the structural failure. An OAuth refresh token is a bearer credential issued after authentication. Once granted, it does not re-present a second factor, it does not expire on password change, and it survives most conditional access policies. Vercel's remediation advice correctly leads with MFA, but MFA on the employee account would not by itself have revoked a token already issued to the application.
On the account attributed to OX Security, the grant arrived through a Chrome extension. Extension installs are rarely governed by the same review as SaaS procurement, yet an extension authenticating with a corporate Google account produces the same standing authorisation as any other OAuth client.
Control of the employee's Google Workspace account converted directly into control of their Vercel account. Single sign-on concentrates that risk by design.
Vercel's Sensitive tier existed before this incident. The customers exposed are those who stored production secrets in the standard tier, the default path of least resistance. A secure option that is not the default is a secure option most customers will not use.
Context.ai's incident is dated March 2026 and Google pulled the extension on March 27, 2026. Vercel discovered the intrusion on April 19, 2026. The extension removal was platform enforcement by Google, not vendor remediation, which means the clearest external signal was generated by a party with no obligation to notify affected tenants.
INDICATORS OF COMPROMISE
- Context.ai Google Workspace application: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com (published by Vercel as an IOC on April 19, 2026)
- Context.ai Chrome extension, holding Google Drive read access: 110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com (identified by Jaime Blasco, Nudge Security)
- Chrome extension IDomddlmnhcofjbnbflmjginpjjblphbgk (removed from the Chrome Web Store by Google on March 27, 2026)
- Lumma Stealer, identified by Hudson Rock as the initial infection at Context.ai in February 2026
Hunting note: both client IDs share the Google Cloud project number 110671459871. Administrators should query Google Workspace token and OAuth grant logs for that project number rather than only the two IDs above, and review any grant to it regardless of the requesting application. Note that Google Workspace OAuth audit logs are retained six months by default on many tiers, which still covers this incident's window.
No malicious domains, IP addresses or file hashes were published in the sources retrieved for this report.
REGULATORY EXPOSURE
For most affected organisations, Vercel is a processor and the customer is the controller. That allocation drives the compliance work here.
- GDPR Article 32 - security of processing, binding on controller and processor alike. Article 32 sits within Articles 25 to 39 and is therefore capped by Article 83(4) at EUR 10M or 2% of annual global turnover, not the higher tier.
- GDPR Article 33(2)a processor must notify the controller without undue delay. Vercel's customers then own the 72-hour clock to their own supervisory authority under Article 33(1). Also Article 83(4). The reported April 10 leaked-key notification, if authentic, raises whether some customers' awareness predated Vercel's April 19 disclosure and started their clock earlier.
- GDPR Article 34 - notification to data subjects where exposed credentials created high risk via downstream systems. A customer-by-customer assessment turning on what each credential unlocked.
- GDPR Article 28 - the vendor that caused this breach was almost certainly not on any sub-processor register. Context.ai was internal productivity tooling adopted by an employee, not a contracted sub-processor. Article 28 governs the vendors an organisation formally engages; it has no reach over the ones staff authorise themselves. That gap is the regulatory story of this incident.
- NIS2 Article 21(2)(d)supply chain security for essential and important entities, with significant incident reporting under Article 23.
- DORA - EU financial entities must maintain a register of information on ICT third-party providers and manage concentration risk. Shadow AI tooling does not appear in such registers, which is precisely the deficiency this incident illustrates.
- UK GDPR and DPA 2018 - mirrors the Article 32 and 33 analysis, under the ICO's standard maximum of GBP 8.7M or 2% of turnover. The GBP 17.5M or 4% higher maximum does not apply to security-of-processing failures.
- CCPA/CPRA - notification duties and the reasonable security standard apply, but the private right of action under Cal. Civ. Code 1798.150 does not attach on these facts. That provision is limited by cross-reference to Section 1798.81.5(d)(1)(A) to categories such as SSN, government identifiers, financial account credentials, medical, biometric or genetic data, or email combined with a password. Names, corporate email addresses, account status and timestamps fall outside it. Statutory damages are not available on the claimed employee file even if it proves authentic.
- FTC Act Section 5 - unfair or deceptive practices. The FTC has repeatedly treated inadequate third-party and vendor access controls as an unfairness theory.
- SEC Item 1.05 - Vercel customers that are SEC registrants must assess whether a third-party incident affecting their production secrets is material to them, and disclose within four business days of that determination. A vendor incident is not automatically immaterial to the customer.
- Saudi PDPL - Gulf controllers deploying on Vercel answer to SDAIA, with fines up to SAR 5M for violations.
- UAE PDPL (Federal Decree-Law No. 45/2021)controller obligations including breach notification to the UAE Data Office apply. The law defers administrative penalties to an implementing Cabinet decision that has not been issued, so no penalty ceiling is currently in force.
INTELLIGENCE GAPS
"Allow All" describes the user's consent action, not the scope strings requested. Without the scope list, no organisation can precisely bound what a compromised grant of the same application could have reached in their own tenant. Administrators can recover this from their own token audit logs; it has not been published centrally.
Vercel frames it as an OAuth application compromise, Context.ai describes a web signup, OX Security via The Hacker News points to a browser extension install, and Hudson Rock documents separate Vercel access held by the infected Context.ai employee. No source reconciles these.
The only statement on the question is an absence-of-evidence hedge from a superseded revision, and the current bulletin is silent.
Vercel published "a limited subset" and "a small number of additional accounts" with no figures. Whether that is dozens or thousands changes the regulatory picture materially.
Trend Micro assesses total dwell time at approximately two months from the February 2026 Lumma Stealer infection to disclosure, correcting an earlier 22-month figure, but that spans the whole chain rather than time inside Vercel.
One single-source data point bears on it: Trend Micro reports a Vercel customer, Andrey Zagoruiko, publicly stating he received an OpenAI leaked-key notification on April 10, 2026 for a key that existed only in Vercel, nine days before disclosure. Trend Micro cautions this "is a single public report, not a forensic finding" and not proof of what Vercel knew. Vercel has published no internal detection timeline.
Hudson Rock names ShinyHunters on infection-database correlation; a GTIG analyst assessed the forum claimant as a likely imposter; actors linked to the brand denied involvement. No forensic attribution has been published, and Mandiant's findings are not public.
Rauch's suspicion is explicitly framed as suspicion, and no forensic indicator distinguishing AI-accelerated operation from competent scripting has been published.
Vercel describes the OAuth app compromise as "potentially affecting its hundreds of users across many organizations," but no list of affected tenants has been released.
ZERO|TOLERANCE Advisory
In the Google Admin console, restrict third-party API access so unconfigured applications cannot be authorised by end users, then export the current list of authorised OAuth applications and their scopes. Treat any grant carrying Drive, Gmail or Admin SDK scopes as privileged access requiring named ownership. The equivalent control in Microsoft 365 is disabling user consent and routing requests through the admin consent workflow.
Given the dispute over whether the grant arrived by web signup or extension install, both paths need coverage. Enforce a Chrome Web Store allowlist through browser management policy, and treat any extension that authenticates with a corporate account as an OAuth client subject to the same review as a SaaS vendor.
The failure that converted a Context.ai breach into a Vercel breach was the absence of a process that revokes third-party OAuth tokens when the third party is compromised. Maintain a mapping of every OAuth application to its vendor, monitor platform enforcement signals such as Chrome Web Store removals rather than relying on vendor notification, and define revocation as the first action, ahead of investigation.
Rotate all values currently held in standard variables and treat them as exposed, per Vercel's own instruction. Do not treat existing Sensitive-tier values as cleared: Vercel has never stated whether they were accessed, and the only statement suggesting otherwise is an absence-of-evidence hedge from a withdrawn revision.
Automated secret scanning from OpenAI, GitHub, AWS, Stripe and Google Cloud now functions as an early-warning channel. A notification for a key that exists only inside a deployment platform is a signal of platform compromise, not routine key hygiene, and in this incident such a notice reportedly preceded public disclosure by nine days.
MFA on the employee account is necessary, but a refresh token already issued to an application is a bearer credential that does not re-challenge. Pair MFA with short token lifetimes, conditional access policies that evaluate the application rather than only the user, and monitoring for token use from anomalous ASNs or geographies.
The Vercel employee did nothing malicious. Shadow AI adoption is a demand signal, and prohibition without provision produces exactly this outcome. Publish an approved AI tool list with pre-reviewed scopes, and make requesting an addition faster than signing up unilaterally.
SOURCES
- Vercel Security Bulletin, "Vercel April 2026 Security Incident" (primary artifact): https://vercel.com/kb/bulletin/vercel-april-2026-security-incident
- Trend Micro Research, "Vercel Breach: OAuth Supply Chain": https://www.trendmicro.com/en_us/research/26/d/vercel-breach-oauth-supply-chain.html
- Hudson Rock, "BREAKING: Vercel Breach Linked to Infostealer Infection at Context.ai": https://www.infostealers.com/article/breaking-vercel-breach-linked-to-infostealer-infection-at-context-ai/
- The Hacker News, "Vercel Breach Tied to Context.ai Hack": https://thehackernews.com/2026/04/vercel-breach-tied-to-context-ai-hack.html
- BleepingComputer, "Vercel confirms breach as hackers claim to be selling stolen data," April 19, 2026: https://www.bleepingcomputer.com/news/security/vercel-confirms-breach-as-hackers-claim-to-be-selling-stolen-data/
- Reco, "Vercel Context.ai Breach" (cited as an example of hedge flattening, not as a factual source): https://www.reco.ai/blog/vercel-context-ai-breach
- Jaime Blasco, CTO, Nudge Security, OAuth client ID and Chrome extension findings, via The Hacker News
- OX Security, initial access vector analysis, as characterised by The Hacker News
- Austin Larsen, Google Threat Intelligence Group, LinkedIn post on actor identity, via The Hacker News
- Guillermo Rauch, CEO, Vercel, April 19, 2026 thread on X, quoted by Trend Micro
- Context.ai security disclosure, quoted in The Hacker News