Vercel / Context.ai - Infostealer at a Vendor → OAuth App Compromise → Google Workspace Takeover → Plaintext Environment Variables Across Customer Projects
On April 19, 2026 Vercel published a security bulletin describing an intrusion that reached its internal systems through a third-party AI tool one of its employees used. Vercel's own account is short and precise: an attacker compromised Context.ai, leveraged that access to hijack the employee's Google Workspace account, then used it to compromise their Vercel account and pivot into internal systems, where non-sensitive environment variables belonging to a subset of customer projects were decrypted and exposed. Independent researchers reconstructed the earlier hops: a Context.ai employee was infected with Lumma Stealer around February 2026, the harvested credentials led to Context.ai's AWS environment and its OAuth application in March, and the OAuth app's broad consent scopes let the attacker mint valid tokens for users who had connected their accounts. The chain never involved a Vercel vulnerability, a stolen Vercel credential, or malware on a Vercel machine. It ran entirely on authorizations that people had legitimately granted.
The first link in a chain that ended inside a major hosting platform was somebody's personal gaming habit. Researchers attribute the initial compromise to Lumma Stealer, an ordinary malware-as-a-service infostealer that has been sold since 2022 and that scrapes browser credentials, session cookies and wallet data for resale on criminal markets. There was no targeting, no zero-day and no sophistication in this step at all. What made it consequential is what the infected machine happened to hold: administrative access to Context.ai's infrastructure and to its OAuth application. This is the same root as UNC5537 / Snowflake, where infostealer logs from unmanaged endpoints became the entry point to 165 organizations, and it is worth noticing how often a purchased log is the beginning of an enterprise incident.
Delivery: A malicious game script or exploit downloaded to a personal machine
Approximate date: February 2026
Harvested: Browser credentials and session tokens, including administrative access to Context.ai infrastructure and its OAuth application
Targeting: None. The victim was opportunistic; the value was discovered afterwards
The stolen administrative credentials led into Context.ai's cloud environment, and from there to the tokens the application stored on behalf of the people who had connected it to their accounts. An AI productivity tool is an unusually dense token store by design: it cannot summarize a user's mail or documents without holding durable access to them, so its database is effectively a directory of standing grants across many organizations. The attacker did not need to compromise any of those organizations. It only needed the vendor that had already been authorized by all of them, which is the same structure that made Salesloft Drift reach 700 Salesforce tenants from one integration.
Reached: Context.ai's AWS environment and the OAuth tokens held for consenting users
Why the vendor is dense: An AI assistant must hold durable read access to mail and documents to function
Effect: One vendor compromise yields standing access across every customer that connected
Researchers describe the OAuth app as having been given "allow all" style permissions during onboarding, which is the ordinary outcome when an employee installs a productivity tool and clicks through the consent screen. Control of the application therefore meant the ability to issue working tokens for any consenting identity, silently. This is the property that makes consent-based access different from a stolen password: there is no login event to alert on, no MFA prompt to fail, and no password reset that revokes it. The grant was made once, by a person acting reasonably, and it stayed valid.
Capability gained: Mint valid tokens for any user who had connected their account
Invisible to the user: No sign-in, no MFA challenge, no notification
Not revoked by: Password resets, credential rotation, or device compliance
Vercel's bulletin states that the attacker leveraged the Context.ai compromise to hijack the employee's Google Workspace account. Researcher accounts differ slightly on the exact surface, describing either a connected OAuth application or a browser extension associated with the tool holding broad read access to the employee's Google Drive; the shared substance is that an employee had personally authorized a third-party AI tool against a corporate identity. That authorization is an identity bridge, and it sits outside the vendor risk process entirely: nobody reviewed Context.ai, because from the company's perspective nobody bought it. This is the hop that turns a small vendor's bad day into a platform's incident.
Accounts differ on: Connected OAuth app versus an associated browser extension with Drive read access
Accounts agree on: Broad, employee-granted access to a corporate identity
Governance gap: Self-service authorization bypasses vendor review, because nothing was procured
Because Vercel accounts can be reached through Google sign-in, control of the Workspace identity converted directly into control of the Vercel account, and the employee's internal access came with it. From there the attacker navigated to the project settings surface where environment variables are managed and began enumerating. Vercel's later guidance is revealing about which controls would have interrupted this: the bulletin's first remediation item is to enable multi-factor authentication using an authenticator app or passkey, followed by reviewing activity logs and recent deployments and enabling Deployment Protection. Federated sign-in inherits the security of the upstream identity, and here the upstream identity had been handed over by an application the employee trusted.
Surface reached: The project environment variables management interface
Vercel's first remediation item: Enable MFA with an authenticator app or passkey
Lesson: Federated login is exactly as strong as the identity provider account behind it
Vercel offers a "sensitive" flag on environment variables. Values marked sensitive are protected so they cannot be read back through the interface; values left unmarked are stored so they decrypt to plaintext and are readable by anyone with project-level permissions. That flag is opt-in, and the name invited exactly the mistake that followed. In practice, teams had left real credentials unflagged: Vercel's own remediation guidance tells customers to rotate the non-sensitive values, and specifically names API keys, tokens, database credentials and signing keys as the kinds of thing to rotate. Nothing was misconfigured in the sense of a broken setting. The classification was simply wrong, and a classification-based control is worth exactly what the classification is worth.
Contents Vercel told customers to rotate: API keys, tokens, database credentials, signing keys
Scope: A subset of customer projects, expanded during the April 22 to 23 investigation
Root cause of the exposure: An opt-in classification flag, not a broken control
Practical response: Pull every variable, scan it for secrets, and rotate upstream before updating the value
Vercel's bulletin runs as a live log: indicators of compromise at 11:04 on April 19, the origin of the attack at 18:01 the same day, clarification on the compromised credentials and npm validation plus MFA guidance on April 20, expanded investigation findings on April 22 and 23 that identified additional affected accounts, and no further updates by April 24. Vercel also noted separate compromise indicators that did not appear to have originated on its systems. Separately, a seller on BreachForums offered what they described as a Vercel database access key and portions of source code for two million dollars. That is an attacker claim advertised on a criminal market, not a confirmed finding, and it should be read as such. Both things can be true at once: the intrusion was real and disclosed, and the sale listing remains unverified.
April 20: Clarification on compromised credentials; npm token validation and MFA guidance
April 22 to 23: Expanded investigation identifies additional affected accounts
Unverified: A BreachForums listing claiming a Vercel database access key and source code, at $2M
Vercel's note: Some separate compromise indicators did not appear to originate on Vercel systems