The breaches that define an era are rarely the ones with the cleverest zero-day. More often they are the ones that expose a structural assumption the whole industry quietly relies on. The Vercel incident disclosed in April 2026 and still generating customer notifications and analysis through May is one of those. No malware ran on Vercel's infrastructure. No CVE was exploited against Vercel's stack. The attackers walked in through an OAuth token that a Vercel employee had granted, months earlier, to a third-party AI productivity tool they had stopped using. That grant outlived the employee's interest in the tool, survived every password rotation, and never once tripped an MFA challenge.
This is the SaaS-to-SaaS supply-chain pattern in its purest form. The trust boundary that failed was not Vercel's login page; it was the silent delegation of identity to a vendor whose own security posture Vercel never controlled. When that vendor, the AI startup Context.ai, was compromised by an infostealer infection in February 2026, every OAuth grant it held became a key to someone else's house. Vercel was one of those houses.
The incident matters disproportionately because of who Vercel is. As the company behind Next.js and a deployment platform used by a large slice of the modern web, Vercel stores the environment variables, API keys, and deployment secrets of an enormous downstream population. A breach of Vercel is not a breach of one company; it is a potential breach of the secrets every Vercel customer pasted into their project configuration. This post reconstructs the attack chain from public reporting, separates what is confirmed from what is inferred, and lays out what SaaS-dependent engineering organizations should do this week.
TL;DR
- An infostealer infection at AI startup Context.ai (reported February 2026) exfiltrated credentials that gave attackers access to Context.ai's environment and the customer OAuth tokens it held.
- One of those tokens was a Google Workspace OAuth grant that a Vercel employee had issued to Context.ai months earlier and never revoked. The grant carried broad ("Allow All") Workspace scopes.
- Using the token, attackers accessed the employee's Google Workspace account without triggering a password or MFA challenge — a valid OAuth access token does not re-prompt for those — then pivoted into internal Vercel systems.
- Vercel published a security bulletin around April 19-20, 2026. Exposure was limited to a subset of customer environment variables (API keys, database credentials, deployment secrets); variables explicitly marked "sensitive" were stored differently and reportedly not in the exposed set.
- Reporting links the activity to the ShinyHunters-branded extortion ecosystem; a ransom demand reported around $2M and attempted sale of stolen metadata on BreachForums followed. These commercial details are reported, not independently confirmed by Vercel.
- The structural failure is OAuth grant sprawl plus shadow AI: third-party tokens that persist long after use, carry excessive scope, and bypass the MFA controls everyone assumes protect the account.
What happened
Public timelines from incident analysts converge on the following sequence. In approximately February 2026, an employee at Context.ai — a third-party AI tool — was infected with infostealer malware (reporting variously cites Lumma Stealer; one writeup describes the family differently, so treat the exact strain as not fully confirmed). The infostealer harvested credentials from the infected host. By March 2026, Context.ai detected unauthorized access to its cloud environment, including access to customer OAuth tokens that Context.ai held on behalf of the organizations that had connected it.
One of those customers was Vercel. At some earlier point, a Vercel employee had connected their enterprise Google Workspace account to Context.ai and approved a broad set of OAuth scopes. The employee subsequently stopped using the tool, but the OAuth grant remained active. OAuth grants do not expire when you lose interest; they persist until explicitly revoked or until an admin policy times them out.
With the stolen OAuth token, the attackers authenticated as the employee against Google Workspace. Because a valid OAuth access (or refreshable) token represents an already-completed authentication, it does not re-trigger a password prompt or an MFA challenge. From the Workspace foothold, the attackers enumerated and pivoted into internal Vercel systems. Vercel published a security bulletin around April 19-20, 2026, and stolen data was advertised by the actors around the same window. Customer notifications and third-party analysis continued through May 2026.
The exposed data was a subset of customer environment variables: API keys, database credentials, and deployment secrets that customers had stored in their Vercel projects. Per Vercel's reporting, environment variables that customers had explicitly flagged as "sensitive" were handled differently and were not part of the exposed set — a distinction that turns out to be load-bearing, and one we return to below.
How the attack worked
The attack chain has five links. None of them is technically sophisticated in isolation; the danger is in the chain.
[1] Infostealer infection at Context.ai (Feb 2026)
| harvests host credentials
v
[2] Attacker accesses Context.ai cloud environment (detected Mar 2026)
| reads CUSTOMER OAuth tokens held by Context.ai
v
[3] Attacker uses Vercel employee's Google Workspace OAuth token
| no password prompt, no MFA challenge (token == prior auth)
v
[4] Pivot from Workspace account into internal Vercel systems
| enumeration, lateral movement
v
[5] Exfiltration of a subset of customer environment variables
(API keys, DB creds, deployment secrets)
The critical mechanic is link 3. A common mental model treats MFA as a wall around the account. But OAuth bearer tokens sit behind that wall. They are issued after authentication succeeds, and they are presented on subsequent requests without re-authenticating. From the identity provider's perspective, a request bearing a valid token from a previously consented application is indistinguishable from legitimate use. There is no anomalous login event to alert on, because there is no login.
This is the same failure class as the 2025 Salesloft Drift incident, where stolen OAuth refresh tokens let an actor query 700-plus Salesforce tenants without ever touching a password. The pattern is documented and recurring. The difference here is the shadow AI dimension: the compromised vendor was an AI tool adopted bottom-up by an individual employee, not a sanctioned enterprise integration vetted by security. The grant existed because an engineer wanted to try an AI assistant, clicked "Allow All," and moved on.
Below is an illustrative sketch of the kind of consent that creates this exposure. This is not functional exploit code — it is a representation of an over-broad OAuth consent to show why the blast radius is so large.
// ILLUSTRATIVE — an over-scoped OAuth grant to a third-party AI tool
// Not a real Context.ai manifest; shown to explain blast radius.
{
"client_name": "AI Productivity Assistant",
"requested_scopes": [
"https://www.googleapis.com/auth/gmail.readonly",
"https://www.googleapis.com/auth/drive",
"https://www.googleapis.com/auth/calendar",
"https://www.googleapis.com/auth/userinfo.profile"
],
"access_type": "offline", // grants a long-lived refresh token
"consent": "individual_user", // no admin review required
"review_status": "never_reviewed"
}
With access_type: offline, the application receives a refresh token that can mint new access tokens indefinitely. Combine that with broad scopes and individual-user consent, and a single stolen token from the vendor's environment becomes durable, MFA-immune access to the employee's mailbox, drive, and — by pivot — the systems that trust that identity.
What detection looks like
Detecting token-replay against a SaaS identity is harder than detecting a bad login, precisely because there is no login. Focus telemetry on the use of tokens rather than the issuance of sessions.
- Anomalous OAuth token use from new infrastructure. In Google Workspace, the
tokenandloginactivity logs record OAuth application access. Alert when a previously-dormant third-party app suddenly resumes activity, or when token use originates from an ASN or geography inconsistent with the user's baseline. - Third-party app inventory drift. Enumerate all OAuth grants in your tenant and flag apps that are (a) consented by individual users rather than admins, (b) holding high-risk scopes (
drive,gmail,mail.read,full), and (c) inactive for an extended period but still granted. - Service-to-service access patterns at the platform layer. For a platform like Vercel, watch for internal enumeration originating from an account whose only recent external activity was a third-party OAuth token, not interactive sign-in.
- Secrets appearing where they should not. Because the exfiltrated data was customer environment variables, downstream victims should hunt for use of those secrets: unexpected API calls authenticated with exposed keys, database connections from new IPs, or deployment-token activity outside CI windows.
An illustrative Workspace audit query concept (adapt to your SIEM):
# ILLUSTRATIVE detection logic, not a literal query
SELECT actor.email, event.app_name, event.ip_address, event.timestamp
FROM workspace_token_audit
WHERE event.app_name IN (known_third_party_ai_tools)
AND event.app_last_active < NOW() - INTERVAL 30 DAY -- dormant then active
AND event.ip_address NOT IN (user_baseline_asn)
ORDER BY event.timestamp DESC
What to do Monday morning
Ordered by urgency for both SaaS providers and SaaS consumers.
- Inventory and triage every third-party OAuth grant in your identity provider. In Google Workspace: Admin Console, Security, API Controls, App access control. In Microsoft Entra ID: Enterprise applications, then review consented permissions. Sort by scope sensitivity and last-active date.
- Revoke dormant and over-scoped grants now. Any individual-user-consented app holding broad mailbox or drive scopes that has been inactive for 30-plus days is a liability with no upside. Revoke first, ask questions later.
- Disable end-user OAuth consent for high-risk scopes. Move to admin-approval workflows so no employee can grant
drive/gmail-class scopes to an unvetted AI tool without review. - If you are a Vercel customer: rotate every secret stored as a plain (non-"sensitive") environment variable. Treat exposed API keys, database credentials, and deployment tokens as compromised. Rotate, then hunt for misuse over the exposure window (roughly February through April 2026).
- Reclassify secrets and adopt short-lived credentials. Where your platform offers a "sensitive" or encrypted-at-rest variable tier, use it. Better still, replace long-lived static secrets with short-lived, dynamically-issued credentials so that a leaked value expires before it can be widely abused.
- Set OAuth refresh-token and session lifetimes. Configure your IdP so that delegated tokens time out. "Valid until revoked" is the default that turns a one-time theft into permanent access.
- Hunt for the infostealer precursor in your own fleet. This chain began with an infostealer on one laptop. Confirm EDR coverage, check for known stealer IOCs, and treat any infostealer detection as a credential-and-token compromise, not just a malware cleanup.
Why this keeps happening
Three structural forces make this incident class inevitable rather than exceptional.
First, OAuth was designed to make delegation frictionless, and it succeeded too well. A user can grant a third party durable, MFA-immune access to their corporate identity in two clicks. The grant has no natural expiry, no mandatory review, and no visibility unless an administrator goes looking. The convenience that drove OAuth adoption is the same property that makes grant sprawl unmanageable.
Second, shadow AI has multiplied the number of vendors holding your tokens. Every employee who connects an AI assistant, a meeting summarizer, or a code helper to their Workspace or Microsoft 365 account is silently expanding the organization's trust perimeter to include that vendor's security posture. You inherit the breach exposure of every tool any employee has ever connected, whether or not your security team knows it exists.
Third, secrets live in too many SaaS control planes as long-lived plaintext. Environment variables, CI/CD secrets, support tickets, and chat logs accumulate static credentials that never rotate. When any one of those control planes is breached, the secrets inside become the attacker's second-stage payload. The Vercel exposure was valuable precisely because it was a concentrated store of other people's secrets.
The structural fix
You cannot eliminate third-party OAuth grants, but you can shorten how long a stolen one stays useful and shrink what it can reach. Two practical levers: minimize the secrets that sit as long-lived plaintext in any SaaS control plane, and continuously inventory where those secrets and tokens live.
This is where secret detection does honest work. Scanning your code, CI/CD configuration, and infrastructure-as-code for embedded credentials would not have stopped the Context.ai infostealer, but it shortens dwell time and reduces blast radius on the part of the chain you control: it surfaces the plaintext API keys and deployment tokens that would otherwise sit in environment variables waiting to be exfiltrated, and it flags them for rotation toward short-lived alternatives. Paired with drift detection over your IaC and platform configuration, you can catch when a "sensitive" variable silently regresses to plaintext, or when an OAuth-app policy drifts away from admin-approval. None of this prevents a vendor breach; it ensures that when one happens, the secrets it exposes are fewer, shorter-lived, and already on a rotation path.
What we know we don't know
Several details remain reported-but-unconfirmed and should not be treated as fact:
- The exact infostealer family is described inconsistently across sources. Treat the strain as unconfirmed.
- The $2M ransom figure and the BreachForums sale appear in secondary reporting, not in a Vercel statement. Treat commercial extortion details as alleged.
- The precise number of affected Vercel customers and the total count of exposed environment variables have not been published in a single authoritative figure at the time of writing.
- Attribution to ShinyHunters is based on overlap with that group's branding and TTPs in the broader 2026 SaaS-extortion wave, not a formal forensic attribution by Vercel.
References
- Trend Micro, "The Vercel Breach: OAuth Supply Chain Attack Exposes the Hidden Risk in Platform Environment Variables": https://www.trendmicro.com/en_us/research/26/d/vercel-breach-oauth-supply-chain.html
- Akeyless, "The Vercel Breach and the Case for Ephemeral Secrets": https://www.akeyless.io/blog/the-vercel-breach-and-the-case-for-ephemeral-secrets/
- Cybersecurity Insiders, "Vercel Breach: How OAuth Sprawl Turned a Forgotten AI App Trial Into a Supply Chain Pivot": https://www.cybersecurity-insiders.com/vercel-breach-oauth-sprawl-shadow-ai-supply-chain/
- CybersecAsia, "Recent breach exposes supply chain risks via OAuth and secrets misclassification": https://cybersecasia.net/newsletter/recent-breach-exposes-supply-chain-risks-via-oauth-and-secrets-misclassification/
- Cyber Defense Magazine, "Why 2026 Will Be The Year Of SaaS Breaches": https://www.cyberdefensemagazine.com/why-2026-will-be-the-year-of-saas-breaches/
Internal reading: