Vercel Breach 2026: Anatomy of a Supply Chain Attack via OAuth

The Vercel breach of April 2026 is a supply chain attack in which the compromise of a third-party AI tool (Context.ai) gave the attacker a valid OAuth token to access a Vercel employee's Google Workspace, which in turn allowed access to internal environments and environment variables not marked as sensitive.

Vercel's perimeter was not breached directly. There was no CVE exploited in their APIs, no RCE, no bruteforce. The entry point was a Chrome extension installed by an employee, authorized via OAuth, with broad permissions. That's the mechanism worth understanding.

Contents

Timeline of events

Date Event
February 2026 a Context.ai employee is infected with Lumma Stealer. Google Workspace, Supabase, Datadog, and Authkit credentials are exfiltrated.
March 2026 Context.ai identifies and blocks unauthorized access to its own AWS. Context.ai's Chrome extension is silently removed from the Chrome Web Store by Google on March 27.
April 2026 (second week) the attacker uses compromised Context.ai OAuth tokens to access the Google Workspace of the affected Vercel account.
April 19, 2026 Vercel publishes its first security bulletin, including the OAuth app IOC.
April 20, 2026 Vercel confirms that npm packages were not compromised. ShinyHunters claims responsibility and puts the data up for sale for $2 million.
April 21, 2026 investigation ongoing with Mandiant, GitHub, Microsoft, npm, and Socket.

The attack chain

It all starts with a Context.ai employee downloading a malicious script distributed as a Roblox exploit. The file installs Lumma Stealer, which silently harvests browser credentials, OAuth tokens, and configuration files from the infected machine. Among the exfiltrated data is the [email protected] account, with privileged access to the company's internal systems.

With those credentials, the attacker enters Context.ai's AWS environment in March 2026. There they find the database of OAuth tokens collected by the Chrome extension: every user who had installed the tool and signed in with Google had left a valid refresh token in their systems. One of those tokens belongs to a Vercel employee who had used their enterprise account to sign up.

The refresh token is enough to obtain a new Google access token without knowing the password and without touching MFA. The attacker accesses Vercel's Google Workspace, identifies the internal environments tied to the account, and reads the environment variables not marked as sensitive. At that point they hold API keys, database tokens, and signing keys for a subset of Vercel customers.

Context.ai: where it all began

Context.ai is an AI tool installed as a Chrome extension that connects to the user's Google account via OAuth. The extension (Chrome Extension ID: omddlmnhcofjbnbflmjginpjjblphbgk) had two active OAuth grants: one to access the user's Google Workspace (Gmail, Calendar, Docs), and one embedded in the extension itself for reading Google Drive files, via the app 110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com.

Jaime Blasco (CTO of Nudge Security) identified that Google removed the extension from the Chrome Web Store on March 27, 2026, well before the Vercel breach became public.

Context.ai confirmed in its own security bulletin that the attacker used a compromised OAuth token to access Vercel's Google Workspace. Vercel is not a direct Context.ai customer, but at least one Vercel employee had installed the extension using their enterprise account and had granted "Allow All" permissions. Vercel's internal OAuth configuration allowed that grant to propagate within their enterprise Google Workspace, making a single employee the entry point for the entire organization.

The role of Lumma Stealer

Lumma Stealer is a malware-as-a-service (MaaS) infostealer, sold on underground forums since 2022. It collects credentials saved in the browser, active session cookies, OAuth tokens and refresh tokens, crypto wallets, and files matching specific patterns like .env, config.json, and id_rsa. Distribution through malicious gaming scripts is a documented technique: the scripts are published as "auto-farm" or "executor" tools on Discord, GitHub, and gaming sites, and users run them believing they're installing a cheat.

In this specific case, Hudson Rock detected that the compromised Context.ai employee's machine contained corporate Google Workspace credentials, Supabase and Datadog tokens, Authkit credentials, and the [email protected] account, which was likely the escalation vector into Context.ai's AWS, where their users' OAuth tokens were stored.

How the OAuth escalation works

When the Vercel employee installs the Context.ai extension and clicks "Sign in with Google," Google shows a consent screen with the requested permission scopes. The user accepts, Google issues an access_token and a refresh_token, and Context.ai saves them in its own AWS systems. From then on, Context.ai uses those tokens to read the user's mail and Drive whenever needed.

So far, this is normal OAuth behavior. The problem is what happens when those tokens fall into the wrong hands.

Once inside Context.ai's AWS, the attacker retrieves the OAuth token database. With the Vercel employee's refresh_token, they call the Google Token Endpoint and obtain a new valid access_token, without knowing the password and without any MFA prompt. At that point they access Vercel's Google Workspace as if they were the legitimate user, identify the internal environments tied to the account, and read the environment variables not marked as sensitive.

The refresh token is permanent until explicitly revoked. Uninstalling the extension does not revoke the grant: until the user removes access from myaccount.google.com/permissions, the token remains valid and exploitable.

Why "Allow All" permissions are dangerous

When an OAuth app requests the scope https://www.googleapis.com/auth/gmail.readonly, Google clearly shows "Read your email messages." When it instead uses aggregated scopes like https://www.googleapis.com/auth/cloud-platform or broad combinations, the consent interface can be less explicit about what's being granted.

A company's Google Workspace policy can restrict which third-party OAuth apps employees are allowed to authorize. If that policy was absent or permissive at Vercel, a single employee was able to grant access that would normally require Google Workspace Admin approval.

What was compromised at Vercel

Confirmed

Environment variables not marked as "sensitive" for a limited subset of customers (API keys, database tokens, signing keys, webhook secrets) were exposed. Vercel contacted the affected customers directly. Access to internal Vercel environments was also confirmed compromised, though its exact nature has not been disclosed.

Confirmed not compromised

Environment variables marked as "sensitive" are stored in a way that makes them unreadable, even by Vercel engineers, and there is no evidence of access. Vercel's npm packages, including Next.js and Turbopack, were verified intact in collaboration with GitHub, Microsoft, npm, and Socket.

Under investigation

The full scope of exfiltrated data, the exact number of affected customers, and which internal systems were reached are still under investigation. Vercel described the threat actor as "highly sophisticated" based on their operational speed and detailed knowledge of their systems.

A note on the ShinyHunters claim: the group stated it stole the data and is selling it for $2 million. However, Austin Larsen of Google Threat Intelligence Group (GTIG) noted that this is likely an impersonator using the ShinyHunters name to boost their own notoriety.

Indicators of compromise (IOC)

OAuth apps to check immediately

Vercel published two IOCs related to Context.ai's OAuth apps. Google Workspace administrators should check whether these apps are authorized in their own tenant.

Main Context.ai OAuth app:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

OAuth app embedded in the Chrome extension (Google Drive read access):

110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com

Chrome extension removed from the Web Store:

Extension ID: omddlmnhcofjbnbflmjginpjjblphbgk

How to check in your own Google Workspace

From the Admin Console: Security > API controls > App access control, searching for the Client IDs listed above.

Via the Google Admin SDK, you can automate an audit of OAuth authorization events:

from googleapiclient.discovery import build
from google.oauth2 import service_account

# requires a Service Account with domain-wide delegation
SCOPES = ['https://www.googleapis.com/auth/admin.reports.audit.readonly']

def check_oauth_app_usage(credentials_file, target_client_id, domain):
    creds = service_account.Credentials.from_service_account_file(
        credentials_file, scopes=SCOPES
    )
    service = build('admin', 'reports_v1', credentials=creds)

    results = service.activities().list(
        userKey='all',
        applicationName='token',
        eventName='authorize',
        filters=f'client_id=={target_client_id}'
    ).execute()

    activities = results.get('items', [])
    if activities:
        print(f"[!] App {target_client_id} authorized by:")
        for activity in activities:
            actor = activity.get('actor', {}).get('email', 'unknown')
            time = activity.get('id', {}).get('time', 'unknown')
            print(f"    - {actor} at {time}")
    else:
        print(f"[+] No authorization found for {target_client_id}")

IOC_MAIN = "110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj"
IOC_DRIVE = "110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq"

check_oauth_app_usage("service-account.json", IOC_MAIN, "yourdomain.com")
check_oauth_app_usage("service-account.json", IOC_DRIVE, "yourdomain.com")

For a single personal Google account, it's enough to go to myaccount.google.com/permissions and check all apps with broad scopes, in particular those with access to Gmail or Drive.

Operational recommendations

For Vercel users

All environment variables not marked as "sensitive" should be treated as compromised and rotated immediately: third-party service API keys, database tokens, JWT secrets, webhook secrets. Deleting the Vercel project or account is not enough, because the exfiltrated credentials remain valid on the destination systems.

# check which env vars are not sensitive via Vercel CLI
vercel env ls --environment production

After rotation, mark everything as sensitive from the dashboard (Settings > Environment Variables > edit > enable "Sensitive") or via CLI:

vercel env add MY_SECRET_KEY production
# the CLI asks whether to mark it as sensitive

Check the activity log for the period April 15-21, 2026 (dashboard > Team Settings > Activity Log) and verify there are no unusual deployments. Make sure Deployment Protection is set to at least "Standard" and rotate related tokens if configured.

For Google Workspace admins

The structural measure is to restrict which third-party OAuth apps employees can authorize on their own. From the Admin Console: Security > API controls > App access control, set "Restrict access to Google services" to "Trusted apps only" and build a list of approved apps.

Beyond the two IOCs published by Vercel, it's worth auditing the existing OAuth apps in the workspace, looking for ones with mail or Drive scopes not justified by their use case, with a publisher not verified by Google, or installed by a very small number of accounts (often just one employee).

For all developers

Use different keys for development and production environments. If a dev key is exfiltrated, production stays intact. On your personal Google or GitHub account, periodically revoke OAuth apps you no longer use, especially browser extensions: they keep access until explicitly removed from the permissions panel, even after uninstallation.

The bigger pattern: OAuth as a lateral vector

This breach isn't isolated. Jaime Blasco of Nudge Security has documented a series of attacks with the same structure over the past year: Salesloft Drift, Gainsight, and now Context.ai/Vercel. The vendor names change, the dynamic stays identical.

New-generation AI and SaaS tools require broad OAuth grants to function (they read mail, Drive, calendar), centralize these tokens in their own cloud systems, and are often young startups without mature security programs. The result is that they become an access hub to dozens or hundreds of enterprise organizations. From the attacker's perspective, compromising a vendor like this is far more efficient than attacking each target individually: it's the same logic that made software supply chain attacks profitable (SolarWinds, 3CX, XZ Utils), applied to the identity layer.

What makes OAuth particularly insidious as a vector is that refresh tokens don't expire unless explicitly revoked, OAuth-based access bypasses MFA without requiring the user's password, and the logs show legitimate accesses because consent was granted voluntarily. There's nothing anomalous to detect until it's too late.

As Blasco wrote: "OAuth is the new lateral movement. Until the industry treats OAuth tokens as high-value credentials, we'll keep reading the same breach writeup with the vendor names changed."

References

  1. Vercel security bulletin - April 2026
  2. The Hacker News - Vercel breach analysis
  3. Google - revoke OAuth app access
  4. Vercel docs - sensitive environment variables
  5. Vercel docs - activity log

Updated as of April 21, 2026. The situation is still evolving: Vercel continues to investigate the full extent of the exfiltration with Mandiant.