The Vercel Breach Was Not a Hack. It Was a Trust Relationship Walking Through an Open Door.
- Patrick Duggan
- 14 minutes ago
- 9 min read
On April 19, 2026, Vercel published a security bulletin confirming unauthorized access to certain internal systems. The story that emerged over the following days is not primarily a story about Vercel's security failures. It is a story about the shape of modern attacks, and why the mental model most defenders are still running is about fifteen degrees off from where the threats actually live.
Understanding this breach fully requires holding three things in your head at once: the technical mechanics of how OAuth sessions work, the economics of what Vercel actually hosts, and the structural pattern that connects this incident to every major supply-chain compromise of the past eighteen months. This post does all three.
The Three Hops Nobody Talks About
Most coverage of the Vercel breach starts at Vercel. That is the wrong starting point.
The actual starting point is a small AI productivity company called Context.ai. Context.ai builds an AI office suite that connects to an employee's data, tools, and applications, letting AI agents run tasks with permissioned context across more than forty integrations. It is the kind of tool a technical employee at a fast-moving company adopts on a Tuesday and connects to their Google Workspace by Thursday, because it makes their work faster and nobody has told them not to.
Sometime around February 2026, a Context.ai employee's laptop was infected with Lumma Stealer. Lumma is a credential-harvesting malware-as-a-service that has been circulating since 2022 and accelerated dramatically in 2025. It targets browser sessions, cookies, and stored credentials. On this particular laptop, it found something more valuable than a password: it found active session state that the attacker could use to access Context.ai's internal systems.
From inside Context.ai, the attacker built a malicious OAuth application. The application's client ID, confirmed by Vercel in their security bulletin, is 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. This is a live indicator of compromise. Any organization whose employees used Context.ai during this window should treat the presence of this OAuth app in their Google Workspace audit logs as a confirmed incident, not a precautionary notice.
The OAuth application was designed to hijack the Google Workspace sessions of Context.ai users. A Vercel employee who used Context.ai was among the hundreds of users affected. The attacker used that hijacked session to access the Vercel employee's Google account, and from there pivoted into the Vercel employee's Vercel account and into Vercel's internal environment.
Three hops. Lumma Stealer to Context.ai, Context.ai to the malicious OAuth app, malicious OAuth app to Vercel. Vercel's own systems were never directly attacked. The attacker walked in through a trust relationship that was already established.
Why Multi-Factor Authentication Did Not Help
This is the part that matters most for defenders who are still treating MFA as a meaningful backstop against modern credential attacks.
MFA works by requiring a second factor at the point of authentication. Once a session is established and an OAuth token is issued, the token represents a persistent authenticated state. The token does not require the user to re-authenticate when it is used. If an attacker obtains an active OAuth token, MFA is not re-triggered. The attacker is, from the system's perspective, the legitimate authenticated user.
The Vercel breach did not bypass MFA. There was nothing to bypass. The OAuth token was already issued. The session was already established. The attacker did not need to authenticate at all. They were already inside.
This is not an edge case. This is the defining characteristic of the OAuth-based attacks that have dominated 2025 and 2026. Evilginx and similar tools use adversary-in-the-middle proxying to capture session tokens at login time. Malicious OAuth applications capture session tokens by persuading users to grant permissions. Lumma Stealer captures session tokens by reading them directly off infected machines. In all three cases, the attacker's goal is the session token, not the password, because the session token is what gets them past MFA without triggering it.
If you are relying on MFA alone to protect enterprise applications, you are solving last decade's problem. The current problem is session token theft, OAuth sprawl, and the uncontrolled proliferation of third-party applications with access to enterprise identity infrastructure.
What Was Stolen and Why Two Million Dollars
Vercel confirmed that attackers accessed and decrypted non-sensitive environment variables from customer projects. That is Vercel's characterization. The characterization is technically accurate but organizationally incomplete.
Environment variables in Vercel are where companies store the secrets that make their applications work. API keys for external services. Database connection strings. Webhook secrets. Service account credentials. Stripe keys. Sendgrid keys. Twilio keys. Cloud provider credentials. The full taxonomy of programmatic access tokens for every upstream dependency a deployed application touches.
Vercel also confirmed that the attackers obtained NPM tokens and GitHub tokens from internal Vercel systems. Vercel hosts a significant portion of the JavaScript ecosystem, including thousands of Web3 and DeFi frontends. It is also a major deployment platform for Next.js applications across every vertical. The people who write the code that gets deployed to Vercel are, in many cases, using NPM tokens to publish packages that other developers install into their own applications.
A stolen NPM publish token for a widely-used package is not a credential. It is a supply chain insertion point. It grants the holder the ability to publish a new version of a package that will be silently pulled into builds running anywhere that package is used. A single high-value NPM token, applied carefully, can insert malicious code into thousands of downstream applications without triggering any of the alerts that a traditional compromise would generate.
This is why the asking price on BreachForums was two million dollars. The attackers were not selling employee PII. They were selling access to the dependency graph of a substantial portion of the JavaScript ecosystem. Vercel confirmed after investigation that the NPM packages themselves were not compromised. The tokens were obtained. The decision was apparently made not to use them in that way, or the detection and response was fast enough to prevent it. But the capability existed.
The Pre-Staged Domain We Found in September 2025
Our domain-scanning infrastructure flagged vercel-sso.com on September 2, 2025. Seven months before the breach.
The domain was registered through Cloudflare's registrar and resolves to an AWS IP address at 52.200.3.33. It follows the exact pattern that ShinyHunters and Scattered Spider have used for credential-harvesting infrastructure: take the target company's name, append sso.com, register it through a privacy-conscious registrar, host it on a major cloud provider to avoid blocklists. The same pattern produced bless-invite.com, workday-nike.com, sharepoint-comcast.com, and the rest of the Evilginx SSO impersonation catalog that EclecticIQ documented.
We did not know in September 2025 that this domain would be associated with a breach at Vercel in April 2026. We knew it was suspicious infrastructure following a documented attacker pattern. We indexed it, tagged it, and it sat in our corpus waiting for an event that would give it context.
This is what left-of-boom threat intelligence looks like in practice. Not prediction. Pattern recognition that runs continuously, indexes what it finds, and waits for the world to catch up.
Whether vercel-sso.com was part of the April 2026 breach chain or was an unrelated piece of ShinyHunters pre-staging that never got used is something we cannot confirm from public data. What we can confirm is that the domain existed seven months before the breach, follows documented attacker methodology, and was targeting Vercel specifically. That is meaningful regardless of whether it connected to the April incident.
Attribution: ShinyHunters, Probably Not
The BreachForums posting used the ShinyHunters identity. Actual ShinyHunters-affiliated operators denied involvement to BleepingComputer. This matters because it shapes how you think about the threat actor and what other activity you correlate against it.
ShinyHunters as a brand has been co-opted, claimed, and contested multiple times. The original operators, the BreachForums infrastructure, and the various affiliated and unaffiliated actors who use the name have had a complicated history since BreachForums was seized and relaunched. When someone posts under the ShinyHunters name in 2026, the question of whether it represents the original organization, an affiliated splinter, or an entirely unrelated actor borrowing brand recognition for credibility is genuinely open.
The Vercel breach characteristics, a Lumma Stealer initial access through a third-party AI tool followed by OAuth session hijacking, are consistent with the broader Coinbase Cartel methodology we have been tracking, the overlapping operational cluster of ShinyHunters, Scattered Spider, and Lapsus$ that has driven the major SaaS breaches of 2025 and 2026. Whether the specific actors were ShinyHunters core operators or peripheral affiliates is a question for the IR firms that have the internal Vercel logs. For defenders, the attribution question matters less than the technique.
The Structural Pattern
The Vercel breach is not an isolated event. It is an instance of a pattern that is now producing multiple incidents per month.
In May 2026, the Miasma campaign compromised thirty official packages under the Red Hat Cloud Services npm namespace by obtaining GitHub Actions OIDC tokens through a compromised CI/CD pipeline. Also in May, TeamPCP's Mini Shai-Hulud variant infected TanStack, Mistral, UiPath, and more than a hundred and sixty other npm and PyPI packages by staging a payload in an orphaned commit and publishing it through a hijacked automated workflow. The Nx developer system compromise that led to a GitHub employee's device being infected through a poisoned Visual Studio Code extension. Every one of these attacks shares the same structural DNA as the Vercel breach: the attacker identifies a trust relationship between the target and something smaller and less defended, compromises the smaller thing, and uses the established trust to walk into the target.
The mental model that most organizations are still running is perimeter-first. The firewall, the VPN, the MFA requirement at the gate. That model is not wrong, but it is radically incomplete. The attacks that are succeeding are not going through the gate. They are going through the service door that the employee productivity tool left open, through the OIDC token that the CI/CD pipeline trusts, through the OAuth session that was still valid after the third-party app was compromised.
The attack surface is the trust graph. Every application an employee installs. Every service that touches the build pipeline. Every OAuth grant sitting in your Google Workspace that was issued to a tool you evaluated in a hackathon two years ago and nobody thought to revoke.
What Defenders Should Do
Review your OAuth grants. In Google Workspace, the admin console shows every third-party application that has been granted access to any account in your organization. Most organizations have dozens of applications with read or write access to employee calendars, email, and Drive that nobody specifically approved and nobody has reviewed since they were granted. Some of those applications still have active tokens. If any of those applications has been compromised, the attacker has an authenticated session into your Google Workspace without triggering any alerts.
The malicious OAuth App ID from the Vercel breach is 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. If this application ID appears in your Google Workspace audit logs, treat it as a confirmed incident.
Rotate environment variables and sensitive credentials for applications deployed on Vercel, particularly if they were created or last rotated before April 2026. The non-sensitive variables that Vercel confirmed were accessed may include credentials for services you consider sensitive. Vercel's definition of non-sensitive refers to those stored without additional encryption at rest, not to the sensitivity of what they grant access to.
Audit your Lumma Stealer exposure surface. Lumma targets browser-stored credentials, cookies, and session tokens across Chrome, Firefox, and Edge profiles. If any employee machine has had an undetected Lumma infection in the past eighteen months, the credentials and session tokens on that machine should be treated as compromised and rotated. Lumma samples are well-represented in current threat feeds, and an EDR capable of detecting it should have signatures.
Treat third-party AI productivity tools as high-risk OAuth applications. They typically request broad scopes, they connect to multiple enterprise services simultaneously, and they are adopted by employees without formal security review because they feel like personal productivity tools rather than enterprise software. A compromised AI office suite has access to everything it was granted access to in every organization whose employees use it.
The IOC Set
Everything documented here is indexed in our corpus. The malicious OAuth App ID was ingested and verified on June 2, 2026. The ShinyHunters infrastructure, including the twenty IPs from EclecticIQ's April 2 report and the Evilginx SSO impersonation domains, has been in our index since April 2026. The vercel-sso.com pre-staged domain has been indexed since the September 2025 scan that first flagged it.
If you pull our STIX feed, the indicators are there. If you are running a SIEM or SOAR that can consume STIX 2.1, you have the IOC set.
The breach happened in April. The pre-staged domain was registered in September 2025. The earliest indicators of attacker interest in Vercel predate the breach by seven months. That is the window that left-of-boom intelligence is designed to close.
The Lesson
Vercel did not get hacked. A small company their employee used for productivity got compromised, and the attacker used the trust relationship between that company and Vercel's identity infrastructure to walk in. The perimeter held. The soft surface bled.
The question every organization should be asking is not whether their perimeter is strong. It is whether they have mapped the trust graph of applications, services, and OAuth grants that surround their perimeter, and whether any of those trusted relationships are currently pointed at something that has been compromised or that could be.
The attacker does not need to break through your wall. They need to find the door someone else left open on your behalf.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.