Vercel April 2026 Security Incident: The Env-Var Rotation Runbook

# Vercel's April 2026 security incident: the env-var rotation runbook

Vercel disclosed a security incident on April 18 (bulletin updated April 19) that matters directly to anyone running infrastructure on the platform. Valtik Studios hosts its website on Vercel. I rotated every secret we had deployed within 30 minutes of seeing the bulletin, and this post is the exact runbook I wish every Vercel customer had open while reading the disclosure.

If you want the broader context on the five April breaches this happened alongside (McGraw-Hill, Rockstar, Drift Protocol, Adobe), the April 2026 breach wave post covers all five with attack attribution. This post stays tight on Vercel: what to do right now, in order, and how to prevent it from biting you again.

#What Vercel says (the short version)

A third-party AI tool was using a Google Workspace OAuth app to access Vercel's internal systems. That OAuth app was compromised as part of a broader attack against the AI vendor. Attackers leveraged the resulting access to read internal Vercel systems for a subset of customers.

The critical detail: environment variables marked Sensitive showed no evidence of unauthorized access. Environment variables NOT marked Sensitive should be treated as potentially exposed.

"Sensitive" is a Vercel dashboard flag that lives per-variable in Project → Settings → Environment Variables. When you set it, the value no longer renders in the UI after save, the API redacts it in most reads, and it does not leak through integration surfaces. Almost every Vercel customer I've worked with leaves it OFF by default, because the flag is opt-in and the UI doesn't warn you it should probably be ON.

That "opt-in" default is the lesson of this incident. Vercel's customers didn't do anything wrong; they just accepted the platform default.

#Rotate everything non-sensitive, in this order

Prioritize by blast radius. A leaked Stripe live key or Anthropic API key is catastrophic. A leaked Mapbox public token is a shrug.

Critical (rotate first):

• Payment provider secrets: Stripe sk_live_*, Square access tokens, Plaid secrets
• AI provider API keys: OpenAI, Anthropic, Mistral, Cohere — these bill per token and get abused fast
• Database credentials: PostgreSQL, MongoDB connection strings, Redis passwords, Supabase service role keys
• Authentication-provider secrets: Auth0 client secrets, Clerk secret keys, Cognito app client secrets, NextAuth AUTH_SECRET
• Cloud provider keys: AWS access keys, GCP service account keys, Azure client secrets
• Webhook signing secrets: anything that lets an attacker forge legitimate-looking events

High (rotate same day):

• Email/SMS provider keys: Resend, SendGrid, Postmark, Twilio, Mailgun
• Analytics + observability: Datadog, PostHog, Sentry DSNs (actually low-harm but still rotate)
• CDN + storage: Cloudflare R2, Backblaze B2, Uploadcare
• OAuth client secrets: any OAUTH_CLIENT_SECRET for SSO providers

Medium:

• Custom signing keys: JWT secrets, CSRF secrets, session cookie secrets
• Internal service keys: HMAC signing secrets between Vercel functions and self-hosted services (we have one, AUTOSCAN_SECRET)

Low (still rotate eventually):

• Values that are public by design: NEXT_PUBLIC_* vars, Mapbox public tokens, public Stripe pk_live_* keys. Nothing leaks because they were already public, but rotating resets anything that might have been observed.

#The rotation procedure that actually works

For each secret, follow this sequence. Skipping steps leads to production outages.

1. Provision the new secret at the issuer. Stripe dashboard, Anthropic console, Auth0 admin, whatever. Name it with today's date so you can trace it later: valtik-vercel-2026-04-19.
2. Do not revoke the old secret yet. You want a window where both work so you can propagate.
3. Paste new value into Vercel. Edit the env var. Check the Sensitive box. Save.
4. Propagate to any other system that shares the secret. If your VPS or CI pipeline has the same Resend key, update it there too. If you have a staging deploy on a different platform, update there.
5. Redeploy. Vercel env var changes don't auto-apply. Click Redeploy on the latest deployment, or push a trivial commit.
6. Verify the new secret is active. Load a page that touches the service (submit a form, trigger a webhook, run a worker). Confirm the new key is being used.
7. Revoke the old secret at the issuer. Only after verification. For Stripe, click the three-dot menu → Delete. For Anthropic, revoke on the Keys page. Etc.

Do not batch-revoke a pile of old keys and then start rotating. Revoke each AFTER its replacement is verified live.

#Audit the Vercel activity log

Vercel → Team Settings → Audit Log. Filter by the last 14 days (cover before the incident window). What you're looking for:

• Logins from IP addresses or geographies that aren't you or your team.
• Environment variable read or edit events you don't recognize. Legitimate reads happen during deploys, but a raw read via API outside deploy context is suspicious.
• Access tokens minted. API tokens created by any automation you don't recognize.
• Team member invites. Anyone added who shouldn't be.
• Project access grants. If someone was added to a project, why.
• Integration installs. New Vercel integrations (GitHub apps, Slack bots, AI tools) added recently.

If you find anything suspicious, screenshot it, then revoke the relevant grant / remove the user / regenerate tokens. Don't delete the audit evidence.

#Prevent it next time: the Vercel hardening checklist

You cannot prevent your platform provider from getting breached. But you can reduce the blast radius when it happens. The following is a 15-minute checklist that any Vercel-hosted team should run today and then revisit quarterly.

1. Mark every secret Sensitive. Default posture. Not opt-in for secrets.

2. Remove stale integrations. Settings → Integrations → review every OAuth grant, every GitHub app, every Slack bot, every AI code-review tool. If you don't use it this quarter, remove it. This is the specific vector that bit Vercel customers.

3. Audit team membership. Settings → Team → Members. Contractors you haven't worked with in 6 months? Remove. Former employees? Remove.

4. Enable SCIM or SSO for team access. If you're on a plan that supports it, require SSO. Reduces "ex-employee still has access" risk.

5. Separate production + preview env vars. Preview deployments inherit env vars by default. Production secrets end up in every PR branch URL. Split them: sensitive values on Production only; a testing tier for Preview.

6. Enable Deployment Protection on previews. Settings → Deployment Protection. Password-gate or Vercel SSO-gate all preview URLs. Otherwise they're publicly discoverable subdomains serving your preview code.

7. Rotate secrets on a schedule. Quarterly for critical, annually for medium-risk. Calendar reminder. This turns a "crisis response" into a "routine hygiene task" and means you've already verified the rotation procedure works.

8. Use per-service scoped API keys. Many providers (Stripe, OpenAI, Anthropic, AWS IAM) let you create narrowly-scoped keys. A key that can only send emails ≠ a key that can also delete email templates and configure DKIM. Smaller scope, smaller blast radius if leaked.

9. Log + alert on unusual API usage. If your Stripe key suddenly starts charging from a new IP, you want a page before the attacker runs a second charge. Most providers have webhooks for anomaly events; wire them to Slack or PagerDuty.

10. Document the rotation procedure for every service. A runbook per secret. When the next incident hits, you shouldn't be Googling "how do I rotate my Auth0 secret" at 2am.

#A note on platform trust

Running on Vercel is still the right default for most Next.js/SvelteKit/Nuxt shops in 2026. Their security posture is above-average, their disclosure practices are responsible, and their engineering is strong. What this incident exposes is a deeper industry problem: your platform's security posture is only as good as the third-party OAuth grants you accepted through it.

Every SaaS product that integrates with your Vercel account, your GitHub org, your Google Workspace, your Slack workspace, your AWS account, widens your attack surface by exactly that SaaS's security posture. A small AI tool used by a hundred companies means a hundred customer accounts at once get reachable when that AI tool gets popped.

The answer isn't "don't use SaaS." The answer is: treat every OAuth grant as an attack surface. Minimize. Audit. Rotate. Assume the vendor will be breached eventually and design your blast radius accordingly.

#What Valtik can help with

If you're on Vercel and want an objective review of your deployment security posture — env var hygiene, preview deployment exposure, integration sprawl, audit log forensics — we do that as part of our Platform Security audits. Usually a half-day engagement for a typical Next.js shop.

Contact: hello@valtikstudios.com

Free website security check: /free-check

Related reading:

• April 2026 breach wave: Vercel, McGraw-Hill, Adobe, Rockstar, Drift Protocol
• Vercel deployment security: 10 misconfigurations that leak secrets in 2026

#Sources

1. Vercel April 2026 Security Incident bulletin
2. Vercel Environment Variables documentation
3. Vercel Deployment Protection