Translated from the original Japanese article
Tech 6 min read

Vercel's April 23 Update Confirms a Pre-existing Compromise Separate from Context.ai—Lumma Stealer Suspected of Targeting Vercel Tokens Directly

Vercel Security OAuth Incident Malware Supply Chain
IkesanContents

Four days after the initial April 19 disclosure (Context.ai Breach Reached Vercel via an OAuth Chain — April 2026 Security Incident), Vercel updated its KB bulletin with a follow-up. The single new data point: Vercel identified “customer accounts with evidence of prior compromise that is independent of and predates this incident.” TechCrunch covered the same day in Vercel says some of its customers’ data was stolen prior to its recent hack.

The wording is brief, but the operational implication is not. It’s no longer just a Context.ai OAuth chain story. Infostealer malware directly targeting Vercel credentials has been running on a separate track, predating this incident.

What Changed Between April 19 and April 23

ItemAs of April 19As of April 23
Compromised customer accountsSubset via Context.aiAbove plus additional accounts notified
Pre-existing compromisesNot mentionedindependent of and predates this incident explicitly noted
Attack vectorsContext.ai OAuth chainAbove plus direct infostealer infection of developer endpoints
npm supply chainUnder reviewConfirmed clean in collaboration with GitHub, Microsoft, npm, Socket

“Independent of and predates” is Vercel’s own wording. The bulletin also explicitly states these compromises “do not appear to have originated on Vercel systems”—this is less about assigning liability and more about signaling that multiple vectors are in play.

Per Vercel CEO Guillermo Rauch’s comment to TechCrunch, attackers were “active beyond that startup’s compromise” and used “malware that compromises computers in search of valuable tokens like keys to Vercel accounts.” In other words, even with the Context.ai OAuth path closed, VERCEL_TOKEN and API keys stolen off individual infected developer machines were being used in parallel.

Tracing Back to Lumma Stealer

Combining additional reporting from Trend Micro, Hacker News, and The Hacker News, the initial infection path at Context.ai becomes visible.

Around February 2026, a Context.ai employee hit Lumma Stealer through a search for Roblox cheats. Lumma Stealer is a typical infostealer that exfiltrates credentials, cookies, OAuth tokens, and clipboard contents from Chrome to a Telegram or C2 server. In this case, Google Workspace credentials plus Supabase, Datadog, and Authkit keys were confirmed taken.

From there, attackers pivoted to Context.ai’s OAuth app permissions, then leveraged the “allow all” grant on a Vercel employee’s Google Workspace account. That’s the confirmed line up to the Vercel side.

flowchart TD
    A[Context.ai employee endpoint<br/>Lumma Stealer infection<br/>around Feb 2026] --> B[Google Workspace credentials<br/>Supabase/Datadog/Authkit keys exfiltrated]
    B --> C[Context.ai OAuth app takeover]
    C --> D[Vercel employee Google Workspace<br/>account takeover via 'allow all']
    D --> E[Lateral movement into Vercel internal systems]
    E --> F[Enumeration and decryption of<br/>non-sensitive environment variables]

    X[Separate infection vector<br/>infostealer directly targeting<br/>Vercel tokens] --> Y[Pre-compromised customer accounts<br/>detected April 23]
    Y --> Z[Independent of the Context.ai incident]

The right branch (X→Y→Z) is what the April 23 update newly confirmed, and timeline-wise it may well have been active before the Context.ai path.

The ShinyHunters BreachForums Listing

Per OX Security’s analysis, in mid-April an actor calling themselves ShinyHunters listed Vercel-related data on BreachForums for $2M. The listing contents:

  • Database access keys
  • Portions of source code
  • Employee account information
  • Collection of API keys

Authenticity is unconfirmed and Vercel has not published counts or content details. Still, the existence of the listing alone is enough reason to rotate VERCEL_TOKEN, GitHub tokens, and npm accounts preemptively.

Where Infostealers Hunt for Keys

If infostealer activity is the root, it’s worth knowing how browsers and operating systems actually store credentials.

Storage locationWhat infostealers grabMitigation
Chrome / Edge password storeSaved passwords, cookies, session tokensAudit browser sync, re-login to Vercel/GitHub/npm as a habit
CLI auth files like ~/.vercel/auth.jsonVERCEL_TOKEN in plaintextvercel logout → re-login to reissue
OS keychain (macOS Keychain, Windows Credential Manager)Some infostealers support thisTie to passphrase, shorten auto-lock
Discord / Telegram clientsLogged-in tokensEnforce MFA, periodic sign-out

Lumma Stealer has particularly aggressively targeted Chrome-family browser stores and OAuth cookies through 2024–2025, putting developer workstations first in line.

The Reality of the sensitive Flag

Vercel environment variables behave differently depending on whether the sensitive flag is set. Unset values are stored as Plaintext or Encrypted and are readable via the dashboard or API. This is what the attacker accessed in this incident. sensitive-marked values become unretrievable from both UI and API once saved, and are only injected at runtime during deployment.

That single flag shrinks the exposure surface by an order of magnitude, which is why Vercel scoped the April 19 announcement to “values not marked sensitive.” Conversely, values without the sensitive flag should be treated as fully exposed, and the April 23 update—broadening the scope further—doesn’t change that calculus.

What to Do Today

In addition to the OAuth audit and sensitive rotation from the earlier article, add infostealer-focused items.

  • Review developer endpoint AV/EDR logs filtered to April, especially events for Chrome password store access and clipboard monitoring
  • Run vercel logout → vercel login across the team to reissue VERCEL_TOKEN. Pay particular attention to endpoints with multiple ~/.vercel config files lingering
  • Delete saved Vercel / GitHub / npm credentials from Chrome / Edge, and consider disabling “save login” browser features team-wide
  • The Google Workspace OAuth app audit shouldn’t stop at Context.ai—extend it to every AI tool approved in the past 6 months. Given ShinyHunters’ activity, this isn’t a Context.ai-only story
  • Inventory every environment variable without the sensitive flag. DB connection strings, payment keys, and third-party delivery keys are the top priority