Skip to content
HACKTECH
Cloud & identityReported Published 3 sources

Vercel breach traced to compromised Context.ai OAuth app in employee's Google Workspace

Vercel disclosed on 19 April 2026 a security incident involving unauthorised access to certain internal Vercel systems. Vercel said the incident originated with a compromise of Context.ai, a third-party AI tool used by an employee: the attacker took over the employee's Vercel Google Workspace account and Vercel account, pivoted into a Vercel environment, and enumerated and decrypted environment variables that were not marked as sensitive. Context.ai said an attacker who accessed its AWS environment in March likely compromised OAuth tokens for some consumer users and appears to have used one to access Vercel's Google Workspace. Vercel notified affected customers and declared the incident closed on 16 October 2026.

  • OAuth
  • Google Workspace
  • shadow AI
  • third-party apps
  • environment variables
  • infostealers
  • Vercel

What the sources report

  • Vercel published the Google OAuth client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com as an indicator of compromise and said the tool's Google Workspace OAuth app was the subject of a broader compromise, 'potentially affecting its hundreds of users across many organizations'.
  • In a statement quoted by The Record, Vercel said environment variables marked 'sensitive' are stored in a manner that prevents them from being read and that it did not have evidence those values were accessed; its bulletin tells customers to rotate non-sensitive values such as API keys, tokens, database credentials and signing keys, and says deleting projects or an account is not sufficient to eliminate risk.
  • Context.ai said Vercel's internal authorisation configurations 'appear to have allowed this action to grant these broad permissions in Vercel's enterprise Google Workspace' after the employee signed up with a work account, The Record reported.
  • The Record reported that multiple research firms traced the chain to an infostealer infection on 17 February allegedly involving a Context.ai employee's device.
  • A seller on a cybercriminal forum claimed to represent ShinyHunters, which denied involvement; The Record reported the hacker demanded a $2 million ransom, while TechCrunch reported a Vercel spokesperson said the company had received no communication from the threat actor, such as a ransom demand.
  • Vercel later identified a small number of additional accounts compromised in the incident, plus a small number of customer accounts with signs of compromise that appear separate from the April incident, and said no npm packages it published were compromised.

What it means for your organisation

A single employee's sign-up to an AI productivity tool left a standing OAuth grant into the corporate Google Workspace, and when that tool's vendor was breached the grant became the attacker's way in. Two configurable controls shaped the outcome: Context.ai says Vercel's Workspace settings allowed the broad permissions, and secrets not marked as sensitive could be decrypted once the attacker was inside.

What we check

  • Review Google Workspace and Microsoft Entra third-party app policies: whether users can consent to unverified apps or high-risk scopes, and which apps already hold broad Gmail, Drive or directory access.
  • Search OAuth token audit logs for the Vercel-published client ID and other unapproved apps, then revoke grants that have no owner or business need.
  • Audit how deployment platforms store secrets: production keys should be write-only or sensitive values, or fetched from a secrets manager, with rotation tested and documented.
  • Run an assumed-breach exercise from a compromised employee SaaS account towards internal platforms, testing session lifetime, device trust and step-up authentication on administrative actions.
  • Check that AI tools connected to corporate identities appear in the third-party risk register and in staff guidance on what may be linked to work accounts.

Sources

Services that cover these checks

  • Cloud configuration review

    An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Red team & purple team

    Objective-based adversary simulation: we agree the objectives, try to reach them over several weeks and measure what your detection and response do along the way. Purple mode runs the same scenarios with your defenders in the room, tuning detection as each technique is replayed.

    Duration: 3 to 6 weeks

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • AI & LLM application testing

    Adversarial testing of features built on large language models: chat assistants, retrieval-augmented search, agents with tool access, and generated output that reaches users or other systems. We test whether the model can be steered into leaking data, taking actions it should not, or passing untrusted output into the rest of your stack.

    Duration: 4 to 10 working days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works