A Roblox auto-farm script. A deprecated AI productivity tool. A Google Workspace OAuth grant nobody thought twice about. Those three things — none of them involving Vercel directly — are what handed a sophisticated threat actor the keys to one of the most widely used developer infrastructure platforms on the internet.

Over the weekend of April 19–20, 2026, Vercel — the company behind Next.js and a deployment platform powering millions of developer applications — confirmed a security breach that exposed internal systems and a limited set of customer credentials. The attack chain is now largely reconstructed, and it is a textbook case study in why third-party AI tool integrations represent one of the most underestimated attack surfaces in enterprise security today.

The breach also carries a dimension beyond the technical: Vercel has been widely expected to pursue an IPO in 2026. An incident of this profile, at this moment, creates reputational and due-diligence pressure that goes well beyond the immediate security response.

The Attack Chain, Step by Step

Stage Zero: The Roblox Exploit That Started It All

Cybercrime intelligence firm Hudson Rock traced the likely origin of the entire incident back to February 2026, when a Context.ai employee downloaded what they believed to be a Roblox “auto-farm” script or game exploit executor. What they actually installed was Lumma Stealer — a widely deployed, commercial infostealer-as-a-service malware that silently exfiltrates browser credentials, session cookies, saved passwords, and OAuth tokens from infected machines.

The employee had sensitive administrative access. Browser history artifacts recovered from the compromised device showed direct access to internal Context.ai endpoints — including Vercel project environment variable settings, admin dashboards, and production logs. The Lumma payload harvested all of it: Google Workspace credentials, Supabase keys, Datadog API tokens, Authkit logins, and critically the support@context.ai account, which carried elevated internal privileges.

That single infection, from a game cheat downloaded on a work-adjacent machine, put everything that followed into motion.

Stage One: Context.ai’s AWS Environment Compromised

By June 2025, Context.ai’s consumer AWS environment had been compromised. The company had built a product called the AI Office Suite — a self-serve workspace allowing consumer users to connect AI agents to external applications including Google Workspace through a third-party integration layer.

The AI Office Suite collected broad OAuth permissions from users who opted in. Any user who granted “Allow All” during onboarding handed the application — and by extension, whoever held its OAuth tokens — broad access to their connected accounts.

In approximately March 2026, Context.ai detected and stopped unauthorized access to that AWS environment. The company hired CrowdStrike for forensic investigation and shut down the consumer product. What they did not do quickly enough: invalidate all OAuth tokens that had been issued to users of the compromised platform. Failure to invalidate those tokens when the environment was shut down compounded the damage significantly.

Stage Two: The Token Replay

Between April 17 and 19, 2026, the attacker used a stolen OAuth token to impersonate a Vercel employee’s Google Workspace account. That employee had signed up for Context.ai’s AI Office Suite using their corporate Vercel Google Workspace account and had granted “Allow All” permissions during setup.

Vercel was not a Context.ai enterprise customer. The employee had simply used a shadow-IT signup with their work email — a routine behaviour that security teams across the industry largely fail to prevent or detect.

Here is where Vercel’s own configuration became a contributing factor. According to Context.ai’s disclosure, “Vercel’s internal OAuth configurations appear to have allowed this action to grant these broad permissions in Vercel’s enterprise Google Workspace.” The attacker did not need to phish or social engineer anyone at Vercel. The OAuth token, replayed months after theft, worked.

Stage Three: Lateral Movement Inside Vercel

From the compromised Google Workspace account, the attacker pivoted into Vercel’s internal environments. Vercel CEO Guillermo Rauch confirmed that the attacker gained access to environment variables designated as “non-sensitive” — a product feature Vercel offers to distinguish secrets that should be encrypted at rest from those considered lower-risk configuration values.

The attacker enumerated those non-sensitive variables and used them to gain further access. Customer environment variables marked as “sensitive” — which Vercel stores encrypted in a manner that prevents direct reading — showed no evidence of compromise at the time of disclosure.

Rauch described the attacker as “highly sophisticated” and noted they moved with “surprising velocity and in-depth understanding of Vercel,” adding his suspicion that the operation was “significantly accelerated by AI.”

Security firm GitGuardian raised an additional concern in post-incident commentary: the framing of environment variables as “non-sensitive” may itself be under-examined. Variables that developers label as non-sensitive — internal service endpoints, feature flags referencing internal systems, configuration values for non-secret systems — can still contain enough context about internal infrastructure to enable further pivoting. The label is a developer judgment call, not a technical guarantee. Vercel customers should review their non-sensitive variables with the same scrutiny now being applied to their sensitive ones.

ShinyHunters Claims Credit — But Is It Really Them?

Within 36 hours of the breach surfacing, a threat actor operating under the ShinyHunters name posted on BreachForums claiming to have Vercel’s data and offering it for sale at $2 million. The claimed dataset included an internal database, employee account records, GitHub tokens, npm tokens, API keys, source code fragments, and activity timestamps. As proof of access, the actor shared a text file containing records for approximately 580 Vercel employees.

Here is the complication: threat actors with known ties to recent ShinyHunters-attributed operations denied involvement to BleepingComputer. The ShinyHunters name has functioned less as a coherent group identity and more as a brand that multiple independent actors have adopted over time. We have covered this group’s pattern of fragmentation and name-adoption previously — in the ShinyHunters triple strike against Crunchbase, SoundCloud, and Betterment and the attack on Harvard’s donor database.

Whether the individual claiming credit here is the actual operator or an opportunist leveraging a well-known moniker for credibility and pricing power is not confirmed. What is confirmed: stolen data is being offered for sale, a ransom figure of $2 million has been communicated, and Vercel has not publicly confirmed or denied ransom negotiations.

The Failures Across the Stack

This incident is not a story of one organisation failing. It is a story of compounding failures across multiple organisations and systems, each individually defensible, collectively catastrophic.

Context.ai ran a consumer AI product with broad OAuth integrations and failed to invalidate all issued tokens when their AWS environment was shut down after a confirmed compromise. SOC 2 Type II certification and ISO 27001 compliance — which their archived security page shows they held — did not prevent this operational failure in incident response sequencing. Compliance is not security.

The Vercel employee used their corporate Google Workspace account to sign up for a consumer AI tool and granted it “Allow All” permissions. Without organisational controls preventing it, most employees will do exactly this.

Vercel’s Google Workspace was configured in a way that allowed an unconfigured third-party OAuth application to request and receive broad permissions from a user. Google Workspace administrators have the ability to restrict this — the default configuration allowing users to grant any permissions to unconfigured apps is what enabled the breach vector.

Vercel’s product design introduced a “non-sensitive” environment variable designation that, while intentional, created a class of secrets readable by anyone who gained sufficient internal access.

CrowdStrike’s initial investigation of the Context.ai breach did not surface the OAuth token theft as a finding requiring revocation — or if it did, the response did not include that step. The issue was only identified after Vercel provided information to Context.ai in April following their own investigation.

The Bigger Picture: AI Tool OAuth Sprawl Is the New Shadow IT

The security community has spent years warning about shadow IT — employees signing up for SaaS tools with corporate credentials, connecting them to corporate data, and creating undocumented access pathways that security teams have no visibility into. AI tools have dramatically accelerated this problem.

The explosion of AI-powered productivity tools and agent platforms between 2024 and 2026 created a new generation of OAuth integrations with unusually broad permission requests. These tools do not just read your email — they need to read, write, search, and act on your behalf across your calendar, drive, contacts, and third-party connected services. Users who want to use them click “Allow All” because that is what the onboarding flow tells them to do.

The attack surface this creates is enormous. Every organisation with liberally approved AI-tool OAuth integrations carries the same class of risk Vercel experienced. The bar for what gets approved has dropped considerably in the AI-tool gold rush of the past 18 months.

Rauch himself acknowledged the implication. The attacker did not need a zero-day. They needed a compromised token from a company Vercel had no direct relationship with, issued to an employee who had signed up for a consumer product with their work account. The attack surface is every OAuth grant your employees have ever made.

The IPO Dimension

Vercel has been widely anticipated to move toward an IPO in 2026, with the company consistently profitable and one of the most prominent names in developer infrastructure. A confirmed breach — with stolen data listed for sale at $2 million and an investigation still active — creates due-diligence pressure at exactly the wrong moment.

Enterprise customers evaluating Vercel, investors conducting pre-IPO diligence, and the broader developer community are now scrutinising the company’s security posture in a way that would not have occurred under normal circumstances. How Vercel handles the investigation, its customer notifications, its transparency about the scope of compromise, and the technical remediation it deploys will be read as signals about its operational maturity.

The breach does not necessarily derail IPO plans. How the company responds to it will matter more than the breach itself.

What You Need to Do Right Now

For Google Workspace Administrators

Navigate to: Google Admin Console → Security → API Controls → Unconfigured third-party apps

The recommended setting: “Allow users to access third-party apps that only request basic info needed for Sign in with Google.”

This prevents any unconfigured OAuth application from requesting access beyond a user’s name, email, and profile picture. Apps that need broader access must be explicitly reviewed and approved by an administrator.

The specific IOC from the Vercel incident: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Check your environment for usage of this app immediately and revoke access where found.

Audit Existing OAuth Grants

Pull your current Google Workspace OAuth app report: Admin Console → Security → API Controls → App access control

Review every application with sensitive scopes: gmail.readonly, calendar, drive, admin.directory. Any application you do not recognise or cannot verify as business-approved should be revoked immediately.

For Vercel Customers

  • Review your account activity log for anomalous access
  • Rotate all environment variables containing secrets not marked as sensitive
  • Enable the sensitive environment variable feature for all future secrets
  • Review recent deployments for unexpected changes
  • Ensure Deployment Protection is set to Standard or higher
  • Rotate Deployment Protection bypass tokens if previously configured

In light of GitGuardian’s assessment, also scrutinise your non-sensitive variables: any value that reveals internal service topology, endpoint addresses, or integration identifiers warrants elevation to sensitive status or removal.

Broader Organisational Controls

Institute a quarterly review of OAuth grants across Google Workspace and Microsoft 365. Restrict OAuth app installation to an allowlist rather than user-driven approval. Require security sign-off for any new OAuth grant carrying sensitive scopes.

The Visibility Gap That Needs Fixing

Security professionals have raised an important architectural point in response to this incident. When a third-party OAuth application is compromised, the app owner does not automatically receive audit logs showing how their tokens were used downstream. In the Google ecosystem, audit logs for OAuth token usage live with the organisation whose account was accessed — Vercel, in this case — not with the application that issued the token.

This creates a genuine visibility gap: the party with the most incentive to detect anomalous OAuth usage (the app owner, who knows their tokens were compromised) does not have access to the data required to detect it. Better notification mechanisms between Google and affected app owners following credential compromise events would meaningfully improve the industry’s ability to contain these incidents faster.

What is not debatable: Context.ai should have invalidated all issued OAuth tokens when it confirmed unauthorized access to its AWS environment in March. That step alone would likely have stopped the Vercel breach entirely.

Current Status (as of April 21, 2026)

The investigation remains active. Vercel is working with Google Mandiant, additional cybersecurity firms, law enforcement, and Context.ai. Next.js, Turbopack, and Vercel’s open-source project supply chain have been examined and are believed to be clean. Customer-facing services remain operational.

Context.ai has published its security update and is directly contacting affected users. The identity of the threat actor behind the BreachForums listing remains unconfirmed — the ShinyHunters brand name on the listing has been denied by actors associated with prior ShinyHunters operations. Ransom negotiation status has not been disclosed.

This is a developing story. The core attack chain is confirmed. The full scope of customer data affected is still being established.

This article draws on disclosures from Vercel, Context.ai, Hudson Rock, BleepingComputer, TechCrunch, The Hacker News, GitGuardian, SecurityWeek, and public commentary from Vercel CEO Guillermo Rauch. The investigation is ongoing.