DEV Community

정상록
정상록

Posted on

Vercel's April 2026 Breach: A 3-Step OAuth Supply-Chain Chain Every Dev Should Read

#security #devops #vercel #oauth

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 gitleaks as 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:

  1. Any third-party tool asking for Google Workspace OAuth requires security-owner approval.
  2. Anything beyond read-only scopes needs a written justification.
  3. OAuth grants unused for 30 days are auto-revoked.

That's the price of admission for living on this much managed infrastructure.

Source

Stay rotated, devs.

Top comments (0)