The compromise of Vercel infrastructure highlights a shift in how threat actors bypass modern hardened perimeters by targeting the session layer and identity providers. This incident resulted in the unauthorised access of project configuration data and environment variables, creating a scenario where the business risk scales with the number of integrated third party services. Engineering leads must view this not as a failure of a single platform, but as a demonstration of how identity delegation through OAuth creates permanent, unmonitored pathways into production environments.
Identity hijacking at the workstation level
The initial intrusion did not target Vercel or its cloud infrastructure. It began with the compromise of a single employee workstation via Lumma Stealer, a sophisticated piece of malware distributed through the Stealer-as-a-Service model. This malware targets Chromium-based browsers to extract sensitive data stored in local SQLite databases, specifically the Login Data, Web Data, and Cookies files.
When Lumma Stealer executes, it does not merely look for plaintext passwords. It seeks the Local State file located in the user data directory, which contains an encrypted AES-256-GCM master key used to protect browser secrets. The malware utilises the Windows CryptUnprotectData API to decrypt this master key. Once the key is obtained, the malware decrypts the session cookies stored in the browser.
By capturing these session cookies, the attacker bypassed the requirement for primary credentials and Multi-Factor Authentication. The stolen session for a Google Workspace account allowed the attacker to inherit the active, authenticated state of the employee. In modern enterprise environments, Google Workspace often serves as the primary Identity Provider. Access to this account provides a gateway to every downstream service connected via Single Sign-On or OAuth integrations.
The mechanics of Lumma Stealer
Lumma Stealer employs a specific technical sequence to ensure the persistence of the stolen identity. After decrypting the browser cookies, the malware packages the data into a compressed format and transmits it to a command and control (C2) server via an encrypted POST request. This package includes the GAUTH (Google Authenticator) tokens and specific session tokens for internal platforms.
The attacker then uses a technique known as session restoration or “cookie carrying.” By importing these stolen cookies into a fresh browser instance, the attacker appears to the service provider as the original user. Because the session was already established and the MFA challenge was satisfied during the initial login on the victim’s machine, the service provider does not trigger a new MFA request. This reveals a significant gap in session management: the lack of hardware-bound sessions or IP-pinning for high-privilege administrative accounts.
In this specific case, the compromised session belonged to an employee who had authorised a third party AI tool, Context.ai, to access their workspace. This connection acted as a bridge, allowing the attacker to move from a compromised workstation to an integrated SaaS environment, and finally into Vercel’s internal project configurations.
OAuth as a persistent trust bridge
The compromise of Context.ai allowed the attacker to utilise existing OAuth tokens. Most engineering teams treat OAuth as a mechanism for temporary access, but the technical reality is that these tokens often have long lifespans or are accompanied by refresh tokens that allow for indefinite renewal.
When a user authorises an integration like Context.ai, they grant a specific scope of permissions. These scopes often include repo access for GitHub or broad read/write access for Google Drive and Workspace APIs. The attacker utilised these delegated permissions to move laterally. This is not a vulnerability in the OAuth protocol itself but a failure in how organisations manage the lifecycle of these grants.
Analysis of common AI integration scopes reveals that they frequently request the https://www.googleapis.com/auth/userinfo.email and https://www.googleapis.com/auth/drive.readonly scopes at a minimum. When these tools are integrated with Vercel or GitHub, they create a chain of trust. If any link in that chain is compromised, the attacker inherits the highest level of privilege available in the chain. The attacker in the Vercel incident did not need to find a zero-day exploit in Vercel. They simply used a valid, authorised token to request configuration data.
Bypassing MFA through session replay
The industry reliance on MFA as a primary defence ignores the reality of session replay attacks. Once a session is established, the MFA token is no longer part of the authentication flow for subsequent requests within that session window. The Vercel incident proves that session longevity is a critical risk factor.
Attackers are increasingly focusing on the __Host- and __Secure- cookie prefixes, which are designed to prevent session fixation but do nothing to stop a wholesale copy of the cookie jar. If the session remains valid for fourteen days or thirty days without re-authentication, the attacker has a massive window of opportunity.
To mitigate this, engineering teams must implement shorter session durations and mandatory re-authentication for sensitive actions, such as viewing environment variables or changing deployment settings. The Vercel breach involved the extraction of environment variables that were not marked as sensitive. This indicates that the attacker was able to query the Vercel API, likely using a stolen session token, to retrieve project-level metadata.
Environment variables as the primary objective
The value of the Vercel breach for the attacker lay in the environment variables. These variables serve as the connective tissue for modern applications, holding API keys for Stripe, AWS secret keys, database connection strings, and integration tokens for other SaaS providers.
During the incident, the attacker targeted variables that were not encrypted at rest within the Vercel dashboard. Vercel distinguishes between “Sensitive Environment Variables” and standard variables. Standard variables are stored in a way that allows them to be viewed in plaintext by users with sufficient permissions in the dashboard. This classification system creates a tiered risk model where only a portion of the application’s secrets are truly protected.
This incident exposes the danger of the “Platform Boundary” fallacy. Many developers assumed that because Vercel is secure, “Standard” variables were safe behind the dashboard. In reality, any variable not explicitly toggled as “Sensitive” remains unencrypted at the platform layer, making it an easy payload for an attacker with hijacked session tokens. A call to GET /v1/projects/{id}/env returns an array of environment variable objects. If a variable is not marked as sensitive, the response includes the value field in plaintext.
The classification problem in Vercel
The breach exposed a fundamental issue with manual secret classification. Developers often move quickly, and the default state for environment variables is often not the most secure. If a developer forgets to check the box to encrypt a variable, that secret is exposed to anyone with access to the UI or the API.
Following the breach, Vercel updated its defaults to prioritise the protection of new variables. However, this does not address the legacy variables already present in thousands of projects across the platform. The responsibility for auditing these secrets falls on the engineering teams.
The technical fallout of exposing non-sensitive variables can be just as severe as losing sensitive ones. For example, exposing a DATABASE_URL that was accidentally left unencrypted allows an attacker to bypass the application layer entirely and target the data layer. The Vercel incident confirms that attackers are actively looking for these misclassifications.
AI integrations and the expansion of the attack surface
The use of AI-connected infrastructure introduces a new category of supply chain risk. These tools require deep integration into the development workflow to provide value. They read code, monitor deployments, and analyse logs. This requires a high level of trust and broad permission scopes.
When an organisation adopts an AI tool, it is not just adding a dependency to its code. it is adding a privileged identity to its infrastructure. These tools are often startups with less mature security postures than the platforms they integrate with. They become the “soft underbelly” of the enterprise.
In this incident, the AI tool was the conduit. The attacker used the tool’s access to reach Vercel. This pattern is becoming common in fintech and healthcare sectors where legacy systems are being wrapped in modern AI-driven interfaces. The speed of AI adoption has outpaced the ability of security teams to perform thorough vendor risk assessments, leading to a proliferation of high-privilege, third-party tokens.
Also Read: The New Insider Threat: How AI Agents Can Exfiltrate Corporate Data
The failure of traditional supply chain models
Standard supply chain security focuses on Software Composition Analysis (SCA) and the integrity of build pipelines. Tools like Snyk or GitHub Advanced Security look for vulnerable packages in package.json or malicious commits in the git history. The Vercel breach bypassed these controls entirely.
The attacker did not modify the code. They did not poison an npm package. They did not compromise the build server. They operated at the identity and configuration layer. This is “Identity Supply Chain” risk. Traditional SCA tools are blind to this vector because the code remains “clean” while the environment it runs in is compromised.
Engineering leads must expand their definition of the supply chain to include every OAuth grant and every service account created for an external integration. A compromised OAuth token for a reporting tool can be just as devastating as a malicious library if that token has the permissions to read environment variables.
Incident response and the remediation path
Vercel’s response to the incident involved several architectural changes intended to limit the blast radius of similar attacks in the future. They implemented more granular controls over who can view environment variables and introduced improved logging for secret access.
Visibility is the primary challenge in remediating identity-based attacks. Most organisations do not log every time an environment variable is accessed via the API. They log logins, but not the specific data egress that happens within a valid session. To defend against this, teams need to implement anomaly detection at the API level. A sudden spike in GET requests for project configuration from a single session should trigger an automatic revocation of that session.
Furthermore, the transition to Workload Identity Federation (WIF) is necessary to move away from long-lived secrets. By using short-lived, platform-issued tokens instead of static API keys stored in environment variables, organisations can ensure that even if a variable is exposed, its utility to an attacker is limited to a very narrow window.
Attribution and Threat Actor Activity
A threat actor using the ShinyHunters persona claimed responsibility on BreachForums and demanded a ransom of $2 million. However, forensic analysts, including those from Google Threat Intelligence Group, suggest this was likely an imposter leveraging the group’s notoriety, as the actual ShinyHunters group denied involvement.
What is consistent across analyses is not identity, but capability. The attacker demonstrated speed, precision, and familiarity with internal system structures. That level of operational awareness suggests prior reconnaissance or access to similar environments. Attribution uncertainty does not change defensive lessons; it often reinforces them.
Technical audit requirements for high trust environments
To secure an infrastructure connected to AI tools and third-party SaaS, engineering teams should implement a rigorous audit of their identity surface area. This goes beyond rotating passwords. It requires a deep dive into the delegation of trust.
The following checklist provides a technical baseline for securing Vercel and similar cloud environments:
- Audit all OAuth applications in Google Workspace and GitHub. Revoke any integration that has not been used in the last 30 days or that requests scopes broader than its functional requirements.
- Implement session length limits for administrative consoles. High-privilege sessions should not persist for more than 8 to 12 hours.
- Enable Hardware-Backed MFA (FIDO2/WebAuthn) for all employees. This is the only effective defence against the session hijacking techniques used by Lumma Stealer, as it ties the authentication to a physical device that cannot be duplicated by malware.
- Use the Vercel API to programme-matically audit all environment variables. Identify any variable that contains strings like KEY, SECRET, TOKEN, or PASSWORD but is not marked as sensitive.
- Move sensitive configuration out of environment variables and into dedicated secret management services like AWS Secrets Manager or HashiCorp Vault. Use these services to inject secrets at runtime, reducing the amount of plaintext data stored in the Vercel dashboard.
- Monitor for unusual IP addresses associated with active sessions. While VPNs and dynamic IPs make this difficult, large geographic shifts (e.g., a session moving from London to an unknown data centre in another country) are clear indicators of cookie carrying.
The Vercel breach serves as a warning that the perimeter is no longer a set of firewalls or even an MFA prompt. The perimeter is the session cookie in the developer’s browser and the OAuth token held by a third-party AI tool. If these are not managed with the same rigour as production code, the infrastructure remains vulnerable regardless of how much is spent on traditional security tooling. The challenge for CISOs is to gain visibility into this “shadow identity” layer before it is used as a bridge into their core systems.
