Apr 19, 2026

An AI Tool I'd Never Heard Of Just Cracked Open Vercel

On April 19 Vercel disclosed a breach. The attacker walked in through a third-party AI tool's OAuth app — and your stack probably trusts ten of those.

Security

Tags (5)

# vercel # supply-chain # oauth # incident-response # security

I was halfway through coffee on a Sunday morning when the Vercel security bulletin landed. Internal systems compromised. A “limited subset” of customers contacted directly. The fix: rotate every environment variable that wasn’t marked sensitive. The cause? An AI tool I’d never heard of, sitting one OAuth grant away from a Vercel employee’s Google Workspace account.

That last part is the bit you should lose sleep over.

What’s confirmed vs what’s marketing

Threat-actor claims and vendor disclosures move at very different speeds. Mixing them is how rumors become facts. Here’s the cleaned-up version, current as of April 20.

Vercel describes the attacker as “highly sophisticated based on their operational velocity and detailed understanding of Vercel’s systems.” Mandiant and additional firms are on the response. That’s the kind of language a vendor uses when the post-mortem is going to take weeks.

The kill chain in five hops

The attack didn’t pierce Vercel’s perimeter. It walked through the front door using a borrowed key — a key one of Vercel’s own employees had handed to a small AI vendor weeks or months earlier.

flowchart TD
  A[Attacker] -->|Compromises| B[Context.ai OAuth app]
  B -->|Workspace tokens| C[Vercel employee Google account]
  C -->|SSO / session| D[Vercel internal env]
  D -->|Read API| E[Non-sensitive env vars]
  D -.->|Blocked: write-only| F[Sensitive env vars]
  E -.->|Downstream blast radius| G[Customer DBs, APIs, clouds]

The IOC Vercel published is concrete enough to act on today. If your Google Workspace tenant has ever granted this app, treat it as compromised.

“Sensitive” env vars are why this isn’t worse

The detail that quietly saved a lot of customers is a feature most teams never bothered turning on: Vercel’s sensitive environment variable mode. Most secrets in most projects are stored as regular env vars, which means the dashboard exposes an endpoint that returns them in plaintext. Convenient for you. Convenient for an attacker who phished the right Google account.

# Regular env var: readable in dashboard, readable via API,
# readable by anyone who can borrow your session
vercel env add DATABASE_URL production

# Sensitive env var: write-once, no read-back endpoint,
# decrypted only at build/runtime injection
vercel env add DATABASE_URL production --sensitive

The --sensitive flag isn’t a UI nicety — it’s a different storage path. Once written, no human or API call can retrieve the plaintext from Vercel. The attacker, holding a perfectly valid session, hit the API for env vars and got back exactly what the API was designed to return: every non-sensitive value in plaintext.

The classic mistake is treating “encrypted at rest” as a synonym for “safe.” It isn’t. Encryption at rest protects you when someone steals the disk. It does nothing when the attacker is logged in as one of you.

Encryption at rest is not access control

A worked example, because this trips up otherwise-careful teams.

# Wrong mental model: "the secret is encrypted, so the breach is contained"
def get_db_url():
    blob = vault.fetch_encrypted("DATABASE_URL")  # encrypted at rest, fine
    return aes_decrypt(blob, key=kms.get_key())   # legitimate decrypt path

# Reality: any caller authorized to invoke get_db_url() gets plaintext.
# A hijacked session is, by definition, an authorized caller.

Decryption happens when an authorized identity asks. If the attacker becomes that identity — via a hijacked OAuth grant, a stolen session cookie, a phished SSO login — the encryption layer is doing its job and handing them the plaintext. The control you actually need is on the authorization side: who can invoke decrypt, under what conditions, leaving what audit trail.

Vercel’s --sensitive mode works because it removes the authorized-read code path entirely. There’s no “decrypt and return” endpoint to abuse — only “decrypt and inject into the build container.” Different threat model, different code path, different blast radius.

The pattern: small AI tools, big OAuth scopes

Vercel isn’t the first this year, and won’t be the last. The shape repeats.

• Salesloft Drift (2025) — OAuth tokens to a chat/lead vendor. Attackers used them to siphon Salesforce data across hundreds of downstream tenants.
• Snowflake customer breaches (2024) — credential reuse, missing MFA, blast radius across every customer of every customer.
• Vercel via Context.ai (2026) — a small AI tool with workspace OAuth scopes. The vendor reportedly had hundreds of users; one of them happened to be a Vercel employee with the right access.

The pattern isn’t “AI tools are uniquely dangerous.” The pattern is trust transference. Every OAuth grant you click through extends your trust boundary to the security posture of whoever runs that integration. A small SaaS with three engineers and no SOC inherits the same trust as your IdP — your users just don’t know it.

The pitfall I keep seeing: teams audit their direct vendors carefully and never look at the long tail of “AI productivity” tools that quietly collected gmail.modify, drive.readonly, and admin.directory.user.readonly over the last year. That long tail is now the most generous initial-access market on the internet.

What to do in the next hour

If you ship to Vercel, this is the short list. Don’t wait for an email saying you’re in the “limited subset.”

# 1. Pull the activity log and grep for anything you didn't initiate
vercel activity --json | jq '.[] | select(.createdAt > "2026-04-12")'

# 2. Re-issue every non-sensitive env var, then mark the new value sensitive
vercel env rm DATABASE_URL production
vercel env add DATABASE_URL production --sensitive

# 3. Audit recent deployments — anything you didn't push gets deleted
vercel ls --scope=your-team

Then in your Google Workspace admin console: search for the OAuth app ID above, revoke it if present, and review every third-party app holding mail.*, drive.*, or admin.* scopes. Most teams find at least one app no one remembers granting.

For credentials stored in Vercel: rotate them at the source first (RDS password, GitHub token, Stripe key), then update the new value as --sensitive in Vercel, then redeploy. Doing it in the wrong order leaves a window where the old key is still live somewhere a stranger can reach.

The takeaway worth keeping

Treat your OAuth grants like you treat your database credentials: rotate them, scope them down, audit them, and assume any vendor holding a token from you is one bad week away from being your problem. The Vercel breach is not a story about Vercel. It’s a story about the soft underbelly of every modern SaaS stack — the third-party tool with three engineers, an OAuth scope they shouldn’t have asked for, and a calendar invite from your CISO they’re never going to see.

Spend twenty minutes today in your Google Workspace admin console. Future-you will thank present-you the next time a security bulletin lands on a Sunday morning.

Sources

• Vercel April 2026 security incident — official bulletin
• Vercel confirms security incident as hackers claim to sell internal access — CyberInsider
• Vercel confirms breach as hackers claim to be selling stolen data — BleepingComputer
• The Vercel Breach: What Actually Happened — dev.to/freerave
• Sensitive environment variables — Vercel docs
• Context.ai security update