Vercel's April 19 Security Incident: What Customers Should Do

On April 19, 2026, Vercel disclosed a security incident involving unauthorized access to certain internal Vercel systems. The following day, Context.ai published its own disclosure confirming that it had detected and stopped an unauthorized AWS access incident in March 2026, and that the same attacker had subsequently pivoted through a compromised OAuth token into a Vercel employee's Google Workspace account. Taken together, the two disclosures describe a supply-chain chain with at least six weeks of attacker dwell time between an initial infostealer infection at Context.ai in February 2026 and Vercel's public disclosure on April 19, 2026.

This post was originally published on the morning of April 19 (UTC) against Vercel's initial bulletin. It has been rewritten multiple times to reflect Rauch's April 19 statement, Vercel's updated bulletin (including the April 20 Deployment Protection additions), Context.ai's April 20 disclosure, tier-1 security coverage from The Register and The Hacker News, and threat-intelligence analysis from Hudson Rock. Every claim below is attributed to its source so you can verify the state of the record yourself. The attack chain spans two companies, two separate forensic investigations (Vercel engaged Mandiant; Context.ai engaged CrowdStrike), and a specific operational mechanism — a Vercel employee's individual signup to Context.ai's consumer AI Office Suite using their enterprise Google Workspace credentials — that is directly reproducible in every organization that uses Google Workspace.

Update timeline — all times UTC unless noted. Vercel's own bulletin stamps its "Last updated" in UTC, so a reader in the Americas may see an event marked "April 20" that is still evening of April 19 locally.

• 2026-02 (approximate): Per Hudson Rock's threat-intelligence analysis, a Context.ai employee's machine is infected with Lumma Stealer malware, reportedly via downloads of Roblox auto-farm scripts and executors (a well-documented Lumma carrier). The stealer exfiltrates Google Workspace credentials including the support@context.ai account, plus keys for Supabase, Datadog, and Authkit. This attribution is from Hudson Rock's cybercrime-database cross-reference, not from Context.ai's own disclosure.
• 2026-03 (Context.ai's stated detection): Per Context.ai's April 20 disclosure, the company detects and stops an unauthorized access incident in its AWS environment affecting its consumer AI Office Suite product. Context.ai engages CrowdStrike for forensic investigation, contacts one identified affected customer, and closes the AWS environment to fully deprecate the consumer product. At this point Context.ai does not publicly announce the incident beyond the directly affected customer.
• 2026-04-19, morning UTC (approximate): Vercel publishes initial bulletin describing "unauthorized access to certain internal Vercel systems" affecting "a limited subset of customers." Recommends reviewing environment variables and using the sensitive flag. Vercel did not publish an exact first-publish timestamp.
• 2026-04-19, 22:38 UTC (6:38 PM ET, as the tweet is rendered on X in viewer-local time): Vercel CEO Guillermo Rauch posts a detailed statement on X naming Context.ai as the AI platform, describing the attack chain, and stating that the attack was likely "significantly accelerated by AI."
• 2026-04-19 evening → 2026-04-20 UTC: Vercel expands the bulletin with the root cause — a compromised Google Workspace OAuth app belonging to "a small, third-party AI tool" used by "hundreds of users across many organizations." Discloses the OAuth client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com, since deleted. Vercel's own timeline table (added late on 2026-04-20 UTC) states 2026-04-20 01:01 UTC for this update, though external observers saw the OAuth details circulate earlier; treat Vercel's precise time with some caution.
• 2026-04-20 UTC: Vercel updates the bulletin with three additional recommendations — investigate recent deployments for anything unexpected, ensure Deployment Protection is set to Standard at minimum, and rotate Deployment Protection tokens if configured.
• 2026-04-20 UTC: Context.ai publishes its own security update linked from the homepage nav ("April Security Notice"). Statement confirms March detection, CrowdStrike engagement, consumer AI Office Suite scope, and that the attacker "appears to have used a compromised OAuth token to access Vercel's Google Workspace" after a Vercel employee "signed up for the AI Office Suite using their Vercel enterprise account and granted 'Allow All' permissions."
• 2026-04-20, 07:31 UTC: The Register publishes Simon Sharwood's dedicated analysis, framing the incident as a shared-responsibility failure across Context.ai's infosec, CrowdStrike's investigation, and Vercel's Google Workspace permissions configuration.
• 2026-04-20 UTC: The Hacker News publishes a comprehensive technical writeup including the full chain; Hudson Rock publishes the Lumma Stealer infection analysis via InfoStealers.
• 2026-04-20, ~18:00–20:00 UTC: Vercel iterates the bulletin repeatedly through the afternoon. First rephrases its scope language away from "compromised credentials" toward "non-sensitive environment variables stored on Vercel that decrypt to plaintext." Two minutes later, removes that affirmative scope sentence entirely. Adds enabling two-factor authentication as a new recommendation alongside the existing Deployment Protection guidance. Further clarifies that deleting Vercel projects or accounts does not eliminate risk from already-exposed secrets; rotation must happen first. Corrects a grammar error from one of the earlier afternoon edits (who's → whose).
• Independent reporting on threat-actor claims: BleepingComputer and CyberInsider confirm threat-actor claims of data for sale with an alleged $2M ransom demand; the actual ShinyHunters group denies involvement.

The attack chain, explained

Combining Vercel's bulletin, Rauch's April 19 statement, Context.ai's April 20 disclosure, and Hudson Rock's threat-intelligence analysis, the attack proceeded in roughly this eight-step sequence. Each step carries its own attribution so you can weight it accordingly.

1. February 2026 — Lumma Stealer infection at Context.ai. Per Hudson Rock's InfoStealers analysis, a Context.ai employee's machine was infected with Lumma Stealer malware. Infection vector per Hudson Rock's forensic review of the stealer logs: downloads of Roblox auto-farm scripts and executors, a well-documented Lumma carrier. This attribution is from Hudson Rock's cybercrime-database cross-reference and not confirmed in Context.ai's own disclosure — treat as speculative-but-reputable threat intel.

2. February 2026 — Credential exfiltration. Per Hudson Rock, the stealer harvested Google Workspace credentials for the affected employee plus keys and logins for Supabase, Datadog, and Authkit. Critically, the compromised records included the support@context.ai account — described by Hudson Rock as "a core Context.ai team member" with elevated access.

3. March 2026 — Unauthorized access to Context.ai's AWS environment. Per Context.ai's April 20 disclosure, the unauthorized actor used the stolen credentials to gain access to Context.ai's AWS environment. Context.ai identified the incident, contacted an identified impacted customer, engaged CrowdStrike for forensic investigation, and "closed the AWS environment, hosting service, and associated resources to fully deprecate the consumer product" — the Context AI Office Suite, launched June 2025 as a self-serve consumer workspace that let users enable AI agents to perform actions across external applications.

4. OAuth token compromise during the Context.ai breach. Per Context.ai: "the unauthorized actor also likely compromised OAuth tokens for some of our consumer users." These tokens had been granted by consumer users of the AI Office Suite with varying Google Workspace scopes.

5. Vercel employee's shadow-IT consumer signup. Per Context.ai: "at least one Vercel employee signed up for the AI Office Suite using their Vercel enterprise account and granted 'Allow All' permissions." Context.ai explicitly notes: "Vercel is not a Context customer." This was not a vetted enterprise integration — it was an individual consumer signup that happened to use enterprise Google Workspace credentials.

6. Pivot from Context.ai OAuth to the Vercel employee's Google Workspace. Per Context.ai: the attacker "appears to have used a compromised OAuth token to access Vercel's Google Workspace." Per The Register's April 20 analysis, Context.ai's OAuth configurations "appear to have allowed this action to grant broad permissions in Vercel's enterprise Google Workspace."

7. Lateral movement from Workspace into Vercel environments. Per Rauch's X statement: "a series of maneuvers that escalated from our colleague's compromised Vercel Google Workspace account" to gain "further access to Vercel environments."

8. Non-sensitive environment variable enumeration. Per Rauch: "Vercel stores all customer environment variables fully encrypted at rest… We do have a capability however to designate environment variables as 'non-sensitive'. Unfortunately, the attacker got further access through their enumeration."

The structural observation worth highlighting: the attacker had approximately six weeks between the February infection and Vercel's April 19 public disclosure. Context.ai detected its own side in March, but the OAuth-token compromise that became the Vercel pivot was not addressed at that point — The Register's Simon Sharwood notes that CrowdStrike's investigation "appears to have missed a trick or two" regarding the OAuth token compromise. Hudson Rock independently observes that the company had obtained the relevant compromised-credential data from its cybercrime intelligence approximately one month before the downstream Vercel breach, and argues earlier revocation "could have completely prevented" the supply-chain escalation.

Vercel has not published IOCs, a precise timeline of attacker dwell time inside Vercel environments, or a specific count of affected customers. Rauch says the number of customers with security impact is "quite limited" and that Vercel has reached out directly to those it has concerns about.

What's confirmed vs what's reported

Security-incident writeups only have value when you can tell the difference between a vendor's official position, a CEO's personal account, independent reporting, and unverified threat-actor claims. This section is organized by source so you can weight each claim accordingly.

Confirmed by Vercel's knowledge base bulletin

Source: vercel.com/kb/bulletin/vercel-april-2026-security-incident

• Unauthorized access to certain internal Vercel systems
• Root cause: a compromised Google Workspace OAuth app belonging to a small, third-party AI tool used by "hundreds of users across many organizations." (Context.ai's own disclosure clarifies these were consumer users of the now-deprecated AI Office Suite, not enterprise integrations.)
• Specific OAuth client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com (since deleted)
• A limited subset of customers was impacted; Vercel is engaging with them directly
• Incident-response experts retained; law enforcement notified; services remain operational
• Recommended customer actions: review activity logs via dashboard or CLI, rotate non-sensitive environment variables, adopt the sensitive flag going forward
• Added on 2026-04-20 UTC: investigate recent deployments for unexpected activity and delete if in doubt; set Deployment Protection to Standard at minimum; rotate Deployment Protection tokens if configured; enable two-factor authentication on Vercel accounts

Confirmed by Vercel CEO Guillermo Rauch (personal X statement)

Source: x.com/rauchg/status/2045995362499076169

• The AI platform is Context.ai
• A Vercel employee's Context.ai use was the initial compromise; attacker pivoted via the employee's Google Workspace account into Vercel environments
• Environment variables are encrypted at rest; the attacker accessed non-sensitive variables via enumeration
• Rauch's personal assessment: "We believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI"
• Vercel's open-source supply chain (Next.js, Turbopack, and related projects) has been analyzed and remains safe
• Response partners: elite cybersecurity firms, industry peers, law enforcement, and Google's Mandiant team (Vercel's forensic partner — separate from CrowdStrike, which Context.ai engaged on its own side)
• New platform capabilities rolled out in response: an environment variable overview page and a better UI for sensitive env var creation and management
• Vercel has reached out to Context.ai to assist with the broader investigation

Confirmed by Context.ai's April 20 disclosure

Source: context.ai/security-update

• Context.ai detected and stopped an unauthorized-access incident in its AWS environment in March 2026 — approximately six weeks before Vercel's April 19 public disclosure
• The affected product was the Context AI Office Suite, a consumer-targeted workspace released in June 2025 that let users enable AI agents to perform actions across external applications via third-party services. This product is now fully deprecated
• Context's enterprise platform runs in customer-controlled environments and was explicitly not affected in this incident
• Context.ai engaged CrowdStrike as its forensic investigator
• "The unauthorized actor also likely compromised OAuth tokens for some of our consumer users"
• "At least one Vercel employee signed up for the AI Office Suite using their Vercel enterprise account and granted 'Allow All' permissions" — Context.ai explicitly states "Vercel is not a Context customer"
• The attacker "appears to have used a compromised OAuth token to access Vercel's Google Workspace"
• Context.ai closed the AWS environment, hosting service, and associated resources to fully deprecate the consumer product; it also hardened its other AWS environment with additional encryption, segmentation, authentication, and monitoring

Reported by threat intelligence (Hudson Rock / InfoStealers)

Source: infostealers.com

• A Context.ai employee was infected with Lumma Stealer malware in February 2026
• Infection vector: downloads of Roblox auto-farm scripts and executors (a well-documented Lumma carrier, per Hudson Rock's forensic review of the stealer logs)
• The stealer exfiltrated Google Workspace credentials plus keys and logins for Supabase, Datadog, and Authkit
• Compromised accounts included support@context.ai, described by Hudson Rock as a core team member
• Hudson Rock states it obtained the compromised credential data via its cybercrime database "over a month ago" (i.e., around March 2026)
• Hudson Rock's editorial position: earlier credential revocation could have prevented the downstream Vercel compromise entirely

This is speculative-but-reputable threat intelligence — Hudson Rock is a known infostealer-focused research firm — but it is not confirmed by Context.ai's or Vercel's public statements, and there is no independent forensic cross-verification as of publication.

Reported by independent news

Sources: BleepingComputer, CyberInsider, The Register (Simon Sharwood), The Hacker News, Decipher

• A threat actor posted on a hacking forum claiming to have Vercel data for sale
• The listing advertised access keys, source code, internal Linear data, NPM tokens, and GitHub tokens
• The actor shared 580 Vercel employee records (names, Vercel email addresses, account status, activity timestamps) as proof
• Per BleepingComputer, the actor claimed to be in contact with Vercel regarding the incident and discussed an alleged $2 million ransom demand
• The actor used the "ShinyHunters" moniker; the actual ShinyHunters group denied involvement when contacted by BleepingComputer. Attribution is likely a copycat or loosely affiliated actor reusing the name
• Vercel is not listed on known ShinyHunters extortion portals
• The Register's editorial framing (Sharwood): a shared-responsibility failure across Context.ai's infosec, CrowdStrike's investigation which "appears to have missed a trick or two" regarding the OAuth token compromise, and Vercel's Google Workspace permissions configuration

Claimed but not verified

• The threat actor's data-for-sale listing has not been independently verified
• Whether any of the listed materials are genuine, exaggerated, or fabricated is unknown as of publication
• The $2M ransom amount and the threat-actor-contact-with-Vercel claim are both from the threat actor's own statements on the forum; neither Vercel nor law enforcement has confirmed them
• Motive (financial, espionage, data theft) has not been established publicly

Why the "non-sensitive" flag mattered here

Rauch's statement clarifies the exact mechanism by which the attacker extracted secrets. Vercel's env var system has two storage paths:

Sensitive environment variables per Vercel's documentation:

• Encrypted at rest; decrypted only at build or runtime
• Cannot be read back via the REST API or the dashboard once set
• Do not appear in deploy logs, preview URLs, or build output

Non-sensitive environment variables:

• Stored in a form readable through the dashboard and REST API
• Can surface in build logs and deploy previews
• Exposed to anyone with read access to the project

The attacker's path through Vercel's internal environments reached the system from which non-sensitive variables are readable. Sensitive variables, per Rauch, remain architecturally protected: "Vercel stores all customer environment variables fully encrypted at rest." The rotation guidance follows directly: rotate non-sensitive env vars; sensitive ones do not require rotation based on this incident.

Who is affected

Vercel is contacting directly impacted customers. Not being on Vercel's contact list is not the same as being cleared — Vercel has iterated on the bulletin's scope language multiple times on 2026-04-20 UTC and has not committed to a number of affected customers.

The precautionary posture is: if any secret in a Vercel project is stored as a non-sensitive env var, rotate it tonight. Not being on Vercel's contact list and not having leaked secrets are different things.

Credentials worth treating as potentially exposed include:

• Database connection strings (Postgres, MongoDB, Supabase, Redis)
• API keys for third-party services (Stripe, OpenAI, Anthropic, SendGrid)
• JWT signing secrets
• Webhook signing secrets
• Feature-flag provider keys
• Analytics or logging API tokens
• Any long-lived credential your Vercel project has stored

How to check and rotate

1. Audit env vars in the Vercel dashboard

Open each project → Settings → Environment Variables. For each entry, check the sensitive toggle.

• Sensitive: ✓ → Safe per Vercel's architecture. No action needed.
• Sensitive: ✗ → Treat as exposed. Rotate, then re-set with the sensitive flag enabled.

2. List env vars programmatically

The dashboard is fine for one project. If you have a dozen, use the Vercel CLI:

vercel env ls

That returns the names and flags (but not the values) for the current project. Anything marked "Plain Text" is a rotation candidate.

For automation across many projects, the REST API returns the same shape. A few lines of shell or Node can enumerate every project in a team faster than the dashboard UI.

3. Rotate each non-sensitive secret at the source

For each exposed credential:

1. Rotate it at the issuing service (database, API provider, etc.)
2. Update the Vercel env var and enable the sensitive flag this time
3. Redeploy
4. Confirm the old credential is revoked, not just replaced

Rotating without revoking leaves the old credential valid — and the premise of this exercise is that a stolen copy may exist.

Deletion is not a substitute for rotation. Vercel added this clarification to its bulletin on 2026-04-20: if a non-sensitive env var was enumerable during the incident window, a stolen copy still works after the project or account is deleted. Rotate first, then decide about project deletion.

4. Check your Vercel access logs

Vercel's team-activity log shows team-member actions. Look for unfamiliar access or unexpected API usage in the period leading up to disclosure. Anything unexplained is worth sharing with Vercel's support team if they reach out.

5. Investigate recent deployments and harden your Vercel account

Vercel's 2026-04-20 UTC bulletin update added several recommendations that were not in the initial guidance, with the list expanded further in a late-afternoon 2026-04-20 UTC revision. Treat these as the second pass, after env var rotation:

• Review recent deployments for anything you did not deploy. Open each project's Deployments tab and look for deployments with unexpected commit messages, unfamiliar authors, or odd timing. Vercel's guidance is explicit: "If in doubt, delete deployments in question." Err toward deletion — you can always redeploy from a known-good commit.
• Set Deployment Protection to Standard at a minimum. Open your project → Settings → Deployment Protection. If it is set to anything less than Standard, raise it now. Standard applies Vercel authentication to preview deployments, which closes the window during which an attacker with a link could hit a preview deployment unauthenticated.
• Rotate your Deployment Protection tokens if you have any configured. Bypass tokens that let CI systems or external tools skip Deployment Protection must be treated as potentially exposed along with your non-sensitive env vars. Rotate each one, update its consumers, and revoke the old token.
• Enable two-factor authentication on every Vercel account. Added to the bulletin in the late-2026-04-20 UTC iteration. 2FA closes the single-factor failure mode on any Vercel account adjacent to the Google Workspace pivot path used in this incident. Enable it from your Vercel account settings under Login & Security.

Deployment Protection configuration is per-project. If you have more than a few Vercel projects, loop through them — a single unprotected project is enough to undermine the rotation you just finished.

Audit your Google Workspace OAuth grants

Vercel is one downstream victim of a broader OAuth compromise. Per Vercel's bulletin, the compromised OAuth app affected "hundreds of users across many organizations." Per Context.ai's disclosure, these were consumer users of the now-deprecated AI Office Suite — people who signed up individually, often using corporate Google Workspace credentials, and granted OAuth scopes to a consumer product. Even if you are not a Vercel customer, if anyone in your organization uses Google Workspace and has ever granted OAuth access to a third-party AI product — enterprise-vetted or shadow-IT consumer signup — you need to check this today.

1. Inventory third-party OAuth apps in your Workspace

As a Google Workspace admin:

1. Go to admin.google.com
2. Navigate to Security → Access and data control → API controls → Manage Third-Party App Access
3. Review every connected app — particularly anything with Workspace API access or broad Gmail, Drive, or Calendar scopes

2. Check for the specific compromised OAuth app

Search your grants for the client ID Vercel disclosed:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

If that client ID appears in your org's grants — even as "deleted" or "revoked" — treat your Workspace as potentially accessed during the compromise window. Audit activity logs for the affected user accounts and rotate any credentials that touched them.

3. Revoke broad scopes you don't need

AI tools routinely request Workspace-wide scopes ("read all Gmail", "access all Drive files") when they only need a narrow capability. Revoke anything broader than the tool actually uses. Every over-scoped OAuth grant is a potential next-Vercel — the attacker who compromises that tool inherits your scopes.

4. Move to OAuth app allowlisting going forward

In admin.google.com → Security → API controls, switch to "Allow users to access only trusted apps" and explicitly approve each third-party integration. That shifts Workspace OAuth from default-allow to default-deny. Slower for end users, but it is the control that stops you from being customer #302 of the next AI tool compromise.

"Significantly accelerated by AI" — what Rauch's framing means

Rauch's statement includes an assessment worth taking seriously but holding carefully: "We believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI. They moved with surprising velocity and in-depth understanding of Vercel."

This is a CEO's personal assessment, not a forensic finding. It has not been corroborated by Mandiant or by third-party incident responders publicly. At the same time, it is not an outlandish claim: Mandiant's M-Trends 2026 report, published in March, documented specific AI-accelerated attacker behaviors observed in 2025 investigations, including:

• Malware families that query LLMs mid-execution — PROMPTFLUX and PROMPTSTEAL were observed actively calling out to large language models to evade detection
• Credential stealers that search for AI tool configurations — QUIETVAULT specifically checks target machines for local AI command-line tools and executes predefined prompts against them
• Mandiant's headline finding: attackers are handing off access in 22 seconds — a pace only reachable with heavy automation or AI assistance

What this means for defenders, independent of the Vercel specifics:

• Response windows are compressing. If attackers are moving at LLM-assisted speed, detection-to-containment time matters more than ever.
• Human-only SOC review is now the slow path. Automated detection and automated credential rotation become minimum table stakes, not nice-to-haves.
• Graph-based blast-radius analysis — knowing immediately which credentials reach which systems — is harder to do manually under that time pressure.

None of that validates Rauch's suspicion for this specific incident. But it explains why the suspicion is plausible and why treating "AI-accelerated adversaries" as a baseline assumption — not an outlier — is reasonable defensive posture in 2026.

Supply chain assurance for open source

Rauch explicitly addresses Vercel's open-source supply chain: "We've analyzed our supply chain, ensuring Next.js, Turbopack, and our many open source projects remain safe for our community."

Per Rauch's statement, there is currently no indication that Vercel-maintained open-source projects were modified by the attacker. Customers using Next.js, Turbopack, and related Vercel OSS do not need to rotate based on release-artifact concerns as of this writing. If that changes, Vercel's bulletin will be updated — follow it directly rather than relying on secondary coverage.

Historical context — this is a four-year-old pattern

OAuth-app supply chain compromises, where attackers pivot through a third-party integration's OAuth access into customer environments, are not new. The Vercel / Context.ai incident is the latest instance of a recurring pattern:

The common thread is structural: organizations grant broad, long-lived OAuth access to third-party integrations (CI providers, AI tools, analytics platforms, sales tools) that sit outside their security perimeter. When any one of those integrations is compromised, the attacker inherits the OAuth access to every customer org that granted it.

What is new in 2026 is the dramatically expanded footprint of third-party integrations with OAuth grants — driven primarily by the rapid proliferation of AI tools across developer and operational workflows. Every new AI tool added to a Google Workspace becomes another potential initial-access vector.

When consumer AI signups become enterprise compromise

The detail that distinguishes this incident from its 2022–2025 predecessors is that the OAuth grant did not come from an enterprise integration that Vercel vetted, contracted, and approved. It came from a single employee signing up for a consumer product — Context.ai's now-deprecated AI Office Suite — using their enterprise Google Workspace credentials and clicking through to "Allow All" permissions on the Google OAuth consent screen.

That makes the defensive posture different from "audit your enterprise SaaS vendor list":

• Every employee with a Google Workspace account is a potential OAuth grant surface. The consent screen for a consumer AI product looks indistinguishable from the consent screen for an enterprise one. Users default to clicking through.
• "Allow All" is the common consumer-SaaS ask. Consumer AI products are often built to act across Gmail, Drive, Calendar, and Contacts — they request those scopes as part of their pitch, and many users grant them without reading.
• The blast radius is the Workspace, not the signup. Once broad scopes are granted to a consumer product, a compromise of that product gives the attacker the same access the employee had — not the access the employee intended to give.

The concrete implication: shadow-IT consumer-AI signups are not a separate risk category from enterprise SaaS vendor risk. They are the same risk, with a larger surface and no procurement checkpoint. The Google Workspace admin control to restrict third-party OAuth grants is the only defense that scales across every employee in an organization regardless of what they sign up for.

Longer-term hardening

• Default everything to sensitive going forward. The sensitive flag is the correct default for any string you would not paste in a public channel. The plain-text default for new env vars is a footgun worth disarming.
• Prefer short-lived credentials over static env vars. OIDC federation with your cloud provider, per-deploy tokens, or runtime-injected credentials from a secrets broker all cut the rotation burden during incidents like this.
• Limit who has env var read access. Vercel team roles control who can read non-sensitive env vars from the dashboard. Audit your team list during this incident and trim anyone who does not need production access.
• Move Google Workspace OAuth from default-allow to default-deny. In admin.google.com → Security → API controls, switch to "Allow users to access only trusted apps" and explicitly approve each third-party integration. This is the one control that closes the shadow-IT consumer-AI signup vector at scale. It slows employee onboarding to new tools; it also stops you from being the next downstream victim of a consumer-AI product compromise.
• Inventory third-party OAuth grants quarterly. Make it a recurring security hygiene item, not a one-time response to this incident. Pay particular attention to grants that include Workspace-wide scopes ("read all Gmail", "access all Drive files") — the blast radius of those grants is the whole Workspace.
• Treat infostealer alerts on corporate devices as credential-compromise events. Hudson Rock's analysis of the Context.ai chain suggests that earlier revocation at the moment of infostealer detection could have prevented the entire downstream Vercel compromise. If an endpoint flags as infected, assume every credential that passed through it since last rotation is compromised and rotate on that basis rather than waiting for confirmation.
• Monitor for use of rotated credentials. Set an alert on your upstream services (database, cloud IAM, API providers) for authentication attempts using the now-invalid credential. If one shows up after rotation, you know the stolen copy was real.

The bigger picture

Three CI/CD-adjacent incidents in six weeks: Trivy, axios on npm, and now Vercel. The Vercel incident adds a dimension the prior two did not: the initial compromise was not of Vercel itself, but of a third-party AI tool that had OAuth access to a Vercel employee's Google Workspace. Vercel is one of many downstream victims of the same upstream compromise.

The pattern generalizes beyond any one vendor:

• Developer platforms and security tools run with privileged access to customer credentials
• SaaS OAuth grants to third-party AI tools now aggregate similar privilege horizontally across hundreds of organizations
• Internal corporate systems — Linear, GitHub, Slack, Google Workspace — become central targets because they aggregate operational secrets
• When those integrations are breached, the blast radius is every downstream org whose data touched the platform

The defensive posture is the same each time: know which secrets touched which systems, keep credentials short-lived, and treat every platform you depend on as potentially breached. The question worth answering before the news arrives — not after — is: "if this vendor is compromised tomorrow, what of ours is reachable through them?"

That is the reachability question we built Juliet to answer for Kubernetes clusters — mapping credentials, workloads, and network paths into a graph so the answer takes minutes instead of a week. The same question applies to every SaaS integration in your organization; OAuth grant sprawl is the Kubernetes RBAC sprawl of the 2026 SaaS stack.

What we don't know yet

Responsible reporting means being explicit about the gaps. Several questions that were open in earlier versions of this post have since been answered by Context.ai's April 20 disclosure and by subsequent reporting — those items have been moved up into the "What's confirmed vs what's reported" section. These items remain open as of publication:

• Vercel has not published a precise dwell time for the attacker in its internal environments. Context.ai has confirmed March 2026 as its own detection point; the pivot-to-Vercel timing has not been narrowed down further publicly.
• No IOCs or TTPs have been published by Mandiant that third-party defenders can hunt against beyond Vercel's single OAuth client ID. Hudson Rock's Lumma Stealer attribution is not a Mandiant- or CrowdStrike-confirmed finding.
• Attacker motive (financial, espionage, data theft, opportunism) has not been established beyond the threat actor's own forum claims.
• Total number of Vercel customers affected has not been disclosed. Rauch says "quite limited" but gives no number.
• Total number of Context.ai consumer users affected has not been disclosed. Context.ai confirms "a subset of consumer users" of the now-deprecated AI Office Suite.
• Whether the threat-actor data-for-sale listing on BreachForums contains genuine, exaggerated, or fabricated materials is unverified as of publication. The $2M ransom demand and the threat-actor-contact-with-Vercel claim are both forum-attributed, not confirmed.
• Other downstream victims beyond Vercel. Context.ai's language implies there were multiple consumer users whose OAuth tokens were compromised; how many of those pivoted into employer environments the way the Vercel employee did is not publicly documented.
• Whether CrowdStrike's March investigation at Context.ai identified the OAuth token compromise. The Register's Simon Sharwood frames this as a gap — CrowdStrike's investigation "appears to have missed a trick or two" — but CrowdStrike itself has not publicly commented on the scope of its forensic work.

We will update this post as new primary-source information becomes available. We do not plan to update based on speculative social-media takes.

Frequently asked questions

Was Vercel hacked?

Yes. Vercel publicly disclosed a security incident on April 19, 2026 involving unauthorized access to certain internal systems. The incident is being called the "Vercel hack" or "Vercel breach" in social and trade press. A limited subset of customers was impacted and is being notified directly by Vercel. Vercel's production hosting services remained operational throughout.

What caused the Vercel breach?

The chain has been reconstructed across four public sources — Vercel's bulletin, CEO Guillermo Rauch's April 19 X statement, Context.ai's April 20 disclosure, and threat-intelligence analysis from Hudson Rock. Starting from the earliest known step: a Context.ai employee was infected with Lumma Stealer malware in February 2026 (per Hudson Rock), which harvested Google Workspace credentials including the support@context.ai account. In March 2026, the attacker used those credentials to access Context.ai's AWS environment (per Context.ai), during which OAuth tokens belonging to consumer users of Context.ai's AI Office Suite were compromised. One of those consumer users was a Vercel employee who had signed up using their enterprise Google Workspace account and granted "Allow All" permissions. The attacker used that compromised OAuth token to access the Vercel employee's Google Workspace, pivoted from there into Vercel's internal environments, and enumerated non-sensitive environment variables. Vercel publicly disclosed on April 19, 2026; Context.ai disclosed on April 20.

Which AI tool was compromised?

Vercel CEO Guillermo Rauch publicly identified the AI platform as Context.ai in a statement on X posted April 19, 2026. Context.ai confirmed this in its own disclosure on April 20, 2026, clarifying that the specific product compromised was the Context AI Office Suite — a consumer-targeted workspace launched in June 2025 that has since been fully deprecated. Context.ai's enterprise platform, which runs in customer-controlled environments, was not affected. The compromised OAuth client ID disclosed by Vercel is 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com, which has since been deleted.

How did the attacker get into Context.ai?

Per Hudson Rock's threat-intelligence analysis via InfoStealers, a Context.ai employee's machine was infected with Lumma Stealer malware in February 2026, reportedly via downloads of Roblox auto-farm scripts and executors — a well-documented carrier for the Lumma family. The stealer exfiltrated Google Workspace credentials (including the support@context.ai core-team account), Supabase, Datadog, and Authkit keys. Hudson Rock states it obtained the compromised-credential data via its cybercrime intelligence database approximately a month before the downstream Vercel compromise, and its editorial position is that earlier revocation could have prevented the pivot. This attribution is not confirmed in Context.ai's own disclosure and has not been corroborated by CrowdStrike or Mandiant publicly — it is speculative-but-reputable threat intelligence.

Who investigated the breach?

Two separate forensic investigations on two sides of the supply chain. Context.ai engaged CrowdStrike per its own disclosure, to investigate the unauthorized AWS access identified in March 2026. Vercel engaged Google's Mandiant team per Rauch's X statement, along with unspecified other cybersecurity firms and law enforcement, to investigate the downstream compromise at Vercel. The Register's Simon Sharwood editorializes that CrowdStrike's March investigation "appears to have missed a trick or two" regarding the OAuth token compromise that later enabled the Vercel pivot — though CrowdStrike itself has not publicly commented on the scope of its March work.

Who is behind the Vercel breach?

A threat actor posted on a hacking forum offering Vercel data for sale while using the "ShinyHunters" moniker. However, the actual ShinyHunters group denied involvement when contacted by BleepingComputer, and Vercel itself has not named any threat actor. The attribution is likely a copycat or loosely affiliated actor reusing a well-known name. Per BleepingComputer, the threat actor has claimed to be in contact with Vercel regarding the incident and described an alleged $2 million ransom demand, though these claims are forum-attributed and not confirmed by Vercel or law enforcement. Motive has not been publicly established.

Should I rotate all my Vercel environment variables?

No. Vercel's sensitive environment variables are architecturally protected — encrypted at rest and not readable via the REST API or dashboard once set. Rauch's statement confirms the attacker's access was limited to non-sensitive environment variables via enumeration. Rotate only env vars not marked sensitive, and enable the sensitive flag on everything going forward.

Are Vercel's sensitive environment variables safe in this breach?

Per Vercel's bulletin and Rauch's direct statement, sensitive env vars are encrypted at rest and were not accessed by the attacker. If you have used the sensitive flag correctly, those values are protected in this incident.

What customer data was stolen?

Vercel has publicly confirmed only that a "limited subset of customers" was impacted, with affected customers being notified directly. Separately, a threat actor posted claims of selling access keys, source code, internal Linear data, NPM tokens, and GitHub tokens, along with 580 Vercel employee records. These claims are unverified by Vercel and are disputed on attribution (the actor claims ShinyHunters, but ShinyHunters denied involvement).

Are Next.js, Turbopack, or other Vercel open-source projects affected?

Per Rauch's April 19 statement, no. Vercel has analyzed its supply chain and reports that Next.js, Turbopack, and related open-source projects remain safe. If that assessment changes, Vercel's bulletin will be updated — follow it directly.

What does "significantly accelerated by AI" mean?

This is CEO Guillermo Rauch's personal assessment in his April 19 statement: "We believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI. They moved with surprising velocity and in-depth understanding of Vercel." It is not a forensic finding. Mandiant's M-Trends 2026 report documents that AI-assisted malware and AI-accelerated attacker behaviors were observed in multiple 2025 incidents, so the claim is consistent with an emerging pattern — but the specific claim about this incident has not been independently corroborated.

Is Vercel still safe to use?

Vercel's production hosting services remain operational per its bulletin. The disclosed incident affected internal Vercel systems, not the platforms customers deploy to. Vercel's response has been notably transparent by industry standards — a named-CEO timeline, disclosure of the OAuth client ID, and active engagement with Mandiant and law enforcement.

How do I mark an env var as sensitive in Vercel?

In the Vercel dashboard: open your project → Settings → Environment Variables. When adding or editing a variable, enable the "Sensitive" toggle. Once marked sensitive, the value cannot be read back in the dashboard — only updated or deleted. Plan your rotations accordingly. Vercel has also announced a new UI for sensitive env var management; the new controls were rolled out during this incident response.

Do I need to rotate Deployment Protection tokens?

Per Vercel's April 20 bulletin update, yes — if you have Deployment Protection tokens configured (used to bypass Deployment Protection from CI or external tools), Vercel recommends rotating them. Treat them the same way you would a non-sensitive env var: rotate, update every consumer, and revoke the old token. Vercel also recommends ensuring Deployment Protection is set to Standard at a minimum on every project, and reviewing recent deployments for anything unexpected.

My team uses Context.ai — are we affected?

Per Context.ai's own disclosure, their enterprise platform runs in customer-controlled environments and was not impacted in this incident. Only the now-deprecated consumer AI Office Suite (launched June 2025) was compromised. If your organization is an enterprise Context.ai customer, Context's statement is that your implementations were not affected. Separately, if any individual at your organization signed up for the consumer AI Office Suite using company Google Workspace credentials — even if informally, outside of an enterprise contract — audit your Workspace OAuth grants for the compromised client ID (110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com) and treat any affected user account's credentials as potentially exposed during the window from March through mid-April 2026.

What are "Allow All" OAuth permissions, and why do they matter here?

When a Google Workspace user signs in to a third-party application via OAuth, the application declares what scopes it needs — for example, read access to Gmail, full access to Drive, calendar events, or Workspace-wide data. The Google consent screen presents these scopes for the user to accept. An "Allow All" grant — the phrase Context.ai uses in its disclosure to describe the Vercel employee's signup — indicates the user approved the full set of requested scopes, which for a consumer AI product typically includes broad Workspace access. Once granted, those scopes persist until the user or a Workspace admin revokes them, and they give the application's OAuth backend the same Workspace access the employee had. In this incident, that meant the attacker who compromised Context.ai's consumer OAuth tokens inherited broad Workspace access to the Vercel employee's enterprise account. Google Workspace admins can restrict this at scale via the API controls admin setting — switching from default-allow to an explicit trusted-apps allowlist.

What should my team do about other AI tools with Google Workspace OAuth access?

Treat every AI tool with Google Workspace OAuth access as a potential next-Vercel. Concretely: audit the OAuth grants on your Workspace (admin.google.com → Security → API controls → Third-Party App Access), revoke any grant with broader scopes than the tool actually uses, move to "Allow users to access only trusted apps" if your Workspace plan supports it, and — critically — extend this audit from just known enterprise integrations to anything employees may have signed up for individually. The structural lesson of this incident is that enterprise-vetted vendor risk and shadow-IT consumer-SaaS risk are the same OAuth-grant risk; the defensive control that scales is Workspace-level OAuth allowlisting, not per-vendor vetting.

Sources

1. Vercel April 2026 security incident — Vercel Knowledge Base (Vercel, last updated 2026-04-20 UTC)
2. Guillermo Rauch — April 19 statement on X (Vercel CEO, 2026-04-19 22:38 UTC / 6:38 PM ET)
3. Context.ai Security Update (Context.ai's own disclosure, published 2026-04-20 UTC)
4. Vercel breach tied to Context.ai hack — The Register (Simon Sharwood, 2026-04-20 07:31 UTC)
5. Vercel Breach Tied to Context AI Hack Exposes Limited Customer Credentials — The Hacker News
6. Breaking: Vercel Breach Linked to Infostealer Infection at Context.ai — InfoStealers / Hudson Rock (Lumma Stealer attribution, threat intelligence)
7. Vercel confirms breach as hackers claim to be selling stolen data — BleepingComputer
8. Vercel confirms security incident as hackers claim to sell internal access — CyberInsider
9. Vercel Says Internal Systems Hit in Breach — Decipher
10. M-Trends 2026 — Google Cloud / Mandiant (for AI-accelerated TTP context)
11. Vercel sensitive environment variables documentation
12. Heroku + Travis-CI OAuth incident — GitHub Security, April 2022 (historical precedent)
13. CircleCI January 4, 2023 incident report (historical precedent)

Questions, or need help assessing exposure across your own SaaS stack? Reach us at contact@juliet.sh. We will update this post as new primary-source information becomes available.