Context.ai Breach Reached Vercel via an OAuth Chain — April 2026 Security Incident
Contents
On April 19, 2026, Vercel published an official KB bulletin titled “April 2026 security incident.” Unauthorized access to internal systems had been detected, and the entry point was an OAuth compromise at a third-party AI tool, “Context.ai.”
This site is also deployed on Vercel, so it isn’t someone else’s problem.
For any environment variable that isn’t explicitly marked sensitive, it’s safer to assume the value has been exposed — if you hold such values, you should rotate them right now.
- Source: Vercel April 2026 security incident
- HN thread: Hacker News discussion
What Happened
A Vercel employee was using Context.ai (an AI-context-sharing SaaS) for work, and Context.ai itself was compromised along with its Google Workspace OAuth app permissions.
The attacker pivoted through that OAuth permission to take over the Vercel employee’s Google Workspace account, and from there expanded access to Vercel’s internal environment.
As a result, the attacker was able to read environment variables from some customer projects — specifically those without the sensitive mark.
Vercel has reached out individually to customers potentially affected, and states that for users who were not contacted, “there is no evidence at this time that credentials or private data have been compromised.”
Attack Chain
flowchart TD
A[Context.ai compromise] --> B[Google Workspace<br/>OAuth app permission theft]
B --> C[Takeover of Vercel<br/>employee Google Workspace account]
C --> D[Unauthorized access to<br/>Vercel internal systems]
D --> E[Reading of environment variables<br/>in some projects<br/>unmarked sensitive ones]
D --> F[Possible viewing of<br/>deployment-related resources]A classic supply-chain path (damage reaches the primary target via a vendor or tool) in which compromise of a single third-party OAuth integration led all the way to infrastructure-core access through an employee account.
Timeline
- April 19, 2026 11:04 AM PST: Vercel publishes the first IOC (Indicator of Compromise)
- April 19, 2026 6:01 PM PST: Vercel discloses that the entry point was via Context.ai, and publishes additional recommendations
- April 20, 2026: Final page update
Published IOC
The OAuth app ID that Vercel published as an IOC is the following (the app itself has already been deleted).
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.comGoogle Workspace admins should check whether this OAuth app (or Context.ai itself) had been authorized in their organization and review audit logs.
The sensitive Flag on Env Vars Decided the Blast Radius
The scope of impact was split by whether an environment variable had the sensitive flag set.
- With
sensitivemark: stored in a form that cannot be read back after creation, and there is currently no evidence the values were retrieved - Without
sensitivemark: stored in a form that can be read back from Vercel’s admin UI or API, so the attacker may have read them
This sensitive option is opt-in (you have to explicitly flip it at creation time) and is disabled by default.
On Hacker News, there was also criticism that “security should be strong by default — opt-in is poor design.”
Practically, it’s safer to assume that some variables that should have been marked sensitive — DB URLs, API keys, and so on — were left unflagged and are mixed in with the exposed set.
What Users Should Check Right Now
Vercel’s guidance plus a few practical additions.
| Item | Detail |
|---|---|
| Rotate env vars | Rotate every variable without the sensitive mark. API keys, DB connection strings, tokens for external services, etc. |
| Review activity logs | In the Vercel Dashboard’s Activity view, check for unexpected deploys or configuration changes |
| Inspect recent deployments | Check vercel.json, build settings, env-var change history, suspicious build commands, and suspicious dependency additions |
| Deployment Protection | Raise it to “Standard or higher” so preview URLs can’t be hit from the outside without authentication |
| Rotate Deployment Protection Bypass tokens | If you use them, regenerate them |
| Google Workspace audit logs | Confirm whether Context.ai (or the OAuth app ID from the IOC) was authorized in your own GWS |
| Audit Context.ai usage | If you use it, follow its own disclosures and response |
Third-Party AI Tools’ OAuth Permissions Became the Main Path
Even when the primary target’s defenses are solid, an AI-related SaaS OAuth app that employees use at work can become the weak point.
With the LLM boom, there is a flow of casually granting Google Workspace authorization to “just try it” AI tools. When one of them gets compromised, an attack path opens through the employee’s account all the way to core business systems.
From a Google Workspace admin perspective,
- Require admin approval for OAuth apps
- Take inventory of scopes granted to the AI-related SaaS you actually use
- Promptly revoke unneeded OAuth apps
are worth revisiting right now on the back of this incident.
Related Past Articles
A few recent Vercel-related articles.
- Next.js / React “React2Shell” Vulnerability Response Notes — A CVSS 10.0 vulnerability from December 2025 that affected the Vercel / Next.js ecosystem
- Lessons From a Vercel Deploy Failure: GitHub Connection and Local Git Config Pitfalls — Operational notes from when this site was re-deployed on Vercel
- Tripping Over Script Chunk Build Errors With Astro 6 + Vercel — On the quirks of Vercel’s build environment
This site is a static build hosted on Vercel, so the number of environment variables used at runtime is small.
Even so, I took the chance to review the Vercel Analytics token and the values referenced at build time. For apps that colocate a DB or API server, the impact has to be much larger — projects that forgot the sensitive mark would be in the roughest spot.