Breaking: Vercel Breach Linked to Infostealer Infection at Context.ai

Following the recent confirmation of the Vercel breach, where threat actors claimed to be actively selling stolen corporate data, Hudson Rock has identified the likely point of origin. Our cybercrime intelligence indicates that a very recent infostealer infection of an employee at a third-party vendor likely resulted in this massive supply chain escalation.

In a February 2026 Lumma stealer infection, a Context.ai employee with sensitive access privileges was compromised. A deep dive into the infected machine’s browser history provides a textbook example of how these breaches originate. Logs indicate the user was actively searching for and downloading game exploits, specifically Roblox “auto-farm” scripts and executors. These types of malicious downloads are notorious vectors for Lumma stealer deployments.

This single infection led to a massive amount of corporate credentials falling directly into the hands of hackers. Notably, a query of Hudson Rock’s extensive cybercrime database reveals that Context.ai only has a single infostealer infection on record, this exact employee from a month prior to the incident. This unique correlation makes it highly probable that this specific infection was the initial access method leveraged by ShinyHunters to infiltrate the organization. Threat actors like ShinyHunters, who frequently target enterprise environments, are well-known to abuse exactly these types of compromised access points to facilitate deeper network intrusions.

The Escalation Path

The extracted data from the infected machine reveals a critical exposure of enterprise tools. The corporate credentials harvested during the attack included Google Workspace credentials, as well as keys and logins for Supabase, Datadog, and Authkit.

Among the heavily sensitive records compromised was the [email protected] account. The exposure of these developer and administrative tools provided the exact leverage needed to escalate privileges, bypass initial security perimeters, and successfully pivot into Vercel’s infrastructure.

Vercel Administrative Access

The compromised user was a core member of the “context-inc” Vercel team. History logs show direct access to critical administrative endpoints, which connects directly to the warnings issued in the official Vercel April 2026 Security Incident bulletin:

• vercel.com/context-inc/valinor/settings/environment-variables: This is where highly sensitive secrets, API keys, and deployment configurations are managed.
• vercel.com/context-inc/valinor/settings: General project-level management.
• vercel.com/context-inc/valinor/logs: Access to production and staging logs, which can be used to enumerate internal environment details.

The Cost of Delayed Remediation

Crucially, Hudson Rock obtained this compromised credential data over a month ago. Had this infostealer infection been identified and the exposed credentials revoked immediately, this entire supply-chain attack could have been completely prevented. This incident heavily underscores the critical importance of rapid detection and quick remediation of infostealer credentials before threat actors have the opportunity to operationalize the stolen access.

60 Seconds Vercel Compromise Check

If you’re looking to verify whether your Google Workspace has been affected by the same vulnerability that hit Vercel, you can perform a quick audit using these steps ⬇️

The goal is to hunt for a specific OAuth Client ID associated with the malicious tool.

Step-by-Step Security Audit:

• Access Your App Management: Navigate to the Google Admin Console and head to the API Controls section. You can jump there directly by going to: https://lnkd.in/gcX-Z-zz
  (Manual Path: Security > Access and Data Control > API Controls > Manage Third-Party App Access)
• Search for the Malicious ID: Apply a filter to the list of “Accessed Apps” using the following Client ID:
  https://110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com/

Interpreting the Results:

• No Results: If the search comes up empty, your workspace likely did not grant permissions to the compromised application.
• App Found: If an entry appears after filtering, it means the malicious app was authorized at some point. You should immediately revoke its access and begin your incident response protocol to check for unauthorized data egress.