On 2026-04-19 (updated 2026-04-20), Vercel published a Security Bulletin confirming unauthorized access to certain internal systems. The technically interesting part isn't "Vercel got hacked." It's how they got hacked: a three-step OAuth chain that started with a third-party AI tool an employee was using.
If you deploy anything on Vercel, you have homework to do this week. Let me break down what happened, what was and wasn't exposed, and the concrete steps that matter.
The attack chain (in one paragraph)
A Vercel employee was using Context.ai, a third-party AI tool. The attacker compromised Context.ai's Google Workspace OAuth application, used it to hijack the employee's Google Workspace account, and from there rode the employee's existing OAuth grant to reach Vercel's internal environment. No MFA bypass. No stolen password. Just a legitimate chain of OAuth consents being inherited by the wrong principal.
[Context.ai] --OAuth--> [Google Workspace] --OAuth--> [Vercel]
^ ^
| |
initial breach reached via
(supply chain) inherited OAuth scopes
What got exposed, and what didn't — the Sensitive flag saved some secrets
Vercel's post is unusually precise about the blast radius, and this is where the architectural lesson lands.
- Non-sensitive environment variables: potentially accessed. Vercel recommends rotating all of them. This is the bucket most teams default into — API keys, DB URLs, JWT secrets, webhook signing keys, LLM credentials.
- Sensitive environment variables: no evidence of access. These are stored encrypted and decrypted only at build time, and the value cannot be retrieved in plaintext from the dashboard after creation.
Same variables. Same account. Same dashboard. One checkbox at creation time. That checkbox was the difference between "needs rotation across your entire production stack" and "probably fine."
The IOC you can act on right now
Vercel and downstream security reports published this OAuth App ID:
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
If you're a Google Workspace admin, go to:
admin.google.com → Security → Access and data control → API controls
→ App access control → Manage Third-Party App Access
Search for that project number (110671459871). If it shows up in your org, you now have a concrete incident to investigate.
Context.ai's OAuth app is being described as part of a larger supply-chain compromise affecting hundreds of orgs — not a Vercel-only issue.
What to do this week — the pragmatic version
Day 0 (today, ~2 hours)
- [ ] Search your Google Workspace for the IOC above
- [ ] Review Vercel Activity Log (dashboard or
vercel ls) for unexpected logins, deployments, env changes - [ ] Upgrade Deployment Protection to at least Standard
- [ ] Revoke unused Deployment Protection bypass tokens
Day 1-7 (rotation week)
Rotate everything that was a non-sensitive env var. Prioritize like this:
| Priority | Category | Examples |
|---|---|---|
| P0 (24h) | Payment / DB | Stripe, Toss, Postgres URL, Redis URL |
| P0 (24h) | Signing keys |
JWT_SECRET, NEXTAUTH_SECRET, webhook signing |
| P1 (48h) | LLM APIs |
OPENAI_API_KEY, ANTHROPIC_API_KEY
|
| P2 (7d) | Messaging / storage | SendGrid, Mailgun, S3, Cloudinary |
Standard rotation flow:
# 1. Issue a fresh value in the provider's console
# 2. Re-add it as a Sensitive env var
vercel env add STRIPE_SECRET_KEY production --sensitive
# 3. Deploy on the new value
git commit --allow-empty -m "rotate: STRIPE_SECRET_KEY"
git push
# 4. After verification, revoke the old value at the provider
For JWT_SECRET-style keys, remember that rotating them invalidates every existing session. Keep a JWT_SECRET_LEGACY for a 24-72h grace window and accept tokens signed with either, then drop the legacy.
Day 8-30 (structural improvements)
- Flip your Google Workspace default OAuth access policy to Restricted; move known-good apps to Trusted, block the rest.
- Introduce a secrets manager (1Password Secrets Automation / Doppler / Bitwarden SM) so that Vercel becomes the injection point, not the source of truth.
- Add a recurring quarterly calendar event: "OAuth audit — Google, GitHub, Vercel, Slack, Notion."
- Install
gitleaksas a pre-commit hook to catch accidental secret prints.
The broader takeaway for devs
The attack that got Vercel wasn't novel cryptography, a zero-day, or MFA bypass. It was OAuth consent being treated as low-stakes by the end user.
In 2026, "Sign in with Google" on a new AI tool is effectively deciding: "I'm willing to let this tool's security posture become the lower bound of my entire Google-connected surface area." That includes Vercel, GitHub, Slack, Notion, Supabase, and anything else federated through your Google ID.
If your team doesn't have an AI-tool adoption policy yet, three lines probably cover most of the risk:
- Any third-party tool asking for Google Workspace OAuth requires security-owner approval.
- Anything beyond read-only scopes needs a written justification.
- OAuth grants unused for 30 days are auto-revoked.
That's the price of admission for living on this much managed infrastructure.
Source
- Vercel Security Bulletin (official): https://vercel.com/kb/bulletin/vercel-april-2026-security-incident
Stay rotated, devs.
