Vercel April 2026 Security Incident — What Happened and What Every Site Owner Must Do

Updated 2026-04-26: Timeline extended through Vercel's April 24 status update. No material changes to the action plan or IOCs below — the bulletin has stabilised and Vercel's most recent entry confirms no new findings.

What happened in 60 seconds

On April 19, 2026, Vercel disclosed a security incident. A Vercel employee's Google Workspace account was compromised through a third-party AI tool called Context.ai. The attacker used that access to move laterally into parts of Vercel's internal systems and read environment variables that weren't marked as "Sensitive."

Three things to grasp:

1. Sensitive env vars were safe. Vercel stores those in a write-only manner that blocks read access. If you ticked "Sensitive" when you added a secret, it wasn't exposed.
2. Non-sensitive env vars may be exposed. These are stored in plaintext. If your API keys, service-account credentials, or database URLs were added as regular env vars, treat them as compromised.
3. No npm packages, no customer source code. Vercel verified that none of its published npm packages were tampered with. Source code access is still under investigation but no evidence so far.

If you host anything on Vercel — a production app, a vibe-coded prototype, a WordPress headless frontend, a landing page — this article walks you through exactly what to do. Different stacks need different responses.

What actually happened — the technical summary

Vercel's disclosure describes a sophisticated attack with a supply-chain root cause. The chain was:

1. An employee of Vercel used a third-party AI tool called Context.ai
2. Context.ai itself was compromised
3. Attacker used that foothold to take over the employee's Google Workspace account
4. With the Google Workspace account, they accessed Vercel's internal environments
5. Inside those environments, they read non-sensitive environment variables belonging to customers — anything stored in plaintext rather than behind the "Sensitive" flag

Vercel's response team assessed the attacker as "highly sophisticated based on their operational velocity and detailed understanding of Vercel's systems."

A specific compromised OAuth App ID was published as an indicator of compromise: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. If your Google Workspace or Vercel-linked Google account ever authorised that OAuth app, revoke it immediately.

Timeline

Date & Time (PST)	Event
April 19, 11:04 AM	Vercel publishes initial indicators of compromise
April 19, 6:01 PM	Public disclosure of the attack origin (Context.ai + Google Workspace takeover)
April 20, 10:59 AM	Clarification on what constitutes "compromised credentials"
April 20, 5:32 PM	Validation that no npm packages published by Vercel were compromised
April 22, 7:58 PM	Vercel publishes investigation findings and additional details
April 23, 9:54 AM	Further clarification of investigation findings
April 24, 4:22 PM	Vercel confirms no new updates; bulletin holds

Vercel engaged Mandiant and other cybersecurity firms, notified law enforcement, deployed additional monitoring, and shipped a product change: new environment variables now default to "Sensitive" on.

How many sites were actually affected?

Vercel has not published an exact customer count. Their language so far is "a limited subset of customers had plaintext environment variables compromised."

Vercel hosts more than one million projects globally as of 2026. Even a small percentage is a large absolute number. Until Vercel publishes scope data, the prudent assumption is:

If you had env vars on Vercel between the time the attacker had access (unknown start date) and April 19, 2026 (incident disclosure), and those vars were not marked "Sensitive," assume they were accessed.

This includes paying customers on Pro and Enterprise plans, Hobby free-tier accounts, and anyone using Vercel to deploy preview environments.

Who's actually at risk — by stack

The risk profile varies dramatically based on what you've deployed on Vercel. Let's break it down.

If you run a production app on Vercel (Next.js, SvelteKit, Nuxt, Remix, etc.)

High risk secrets in a typical production setup:

• Database connection strings (PostgreSQL, MongoDB, MySQL URLs with credentials)
• Stripe or Razorpay live API keys
• Firebase Admin SDK private keys
• AWS access keys (S3, SES, other services)
• OpenAI / Anthropic / other AI API keys
• SendGrid, Resend, Mailgun API keys
• JWT signing secrets
• Webhook HMAC secrets
• Third-party OAuth client secrets

If any of these were stored in Vercel without the "Sensitive" flag ticked, rotate them today.

If you built a vibe-coded app on Vercel

"Vibe coding" — the recent practice of prompting AI tools (Cursor, v0, Bolt, Lovable, Claude Code, Replit Agent) to generate full applications without writing the code yourself — has exploded in the last 18 months. Many vibe-coded apps deploy directly to Vercel through one-click integrations.

Why vibe-coded apps are especially exposed in this incident:

1. Creators often don't know which env vars are secrets. When an AI tool tells you "add OPENAI_API_KEY to your environment variables," the typical vibe-coded app creator pastes it into Vercel's UI without understanding the Sensitive flag exists.
2. Every deployment needs its own fresh rotation. Vibe coders often reuse the same API keys across 5+ experimental projects. One exposure compromises all of them.
3. Third-party integrations stack up fast. A vibe-coded SaaS app might have 10-15 env vars: OpenAI, Anthropic, Supabase, Clerk, Resend, Stripe, analytics, etc. That's a big rotation surface.
4. Less logging, less audit. Production apps usually have monitoring to detect abuse. Prototypes rarely do.

If you run WordPress hosted on Vercel (headless or proxied)

While WordPress is traditionally hosted on LAMP stacks, some setups use Vercel in front of WordPress for performance or architecture reasons:

• Headless WordPress — WordPress backend serves data via REST or GraphQL, with a Next.js or SvelteKit frontend on Vercel
• Static WordPress — Content pulled at build time from a WordPress install, deployed as static pages on Vercel
• Vercel as CDN/proxy — Less common, but some setups route through Vercel for the edge network

Risk vectors specific to WordPress-on-Vercel setups:

• WordPress REST API base URL with admin application passwords
• Headless CMS API keys (WPGraphQL endpoints with tokens)
• Direct MySQL connection strings if Vercel talks to the WP database
• JWT secrets for authenticating front-end users against WordPress
• Preview mode secrets (used to preview draft content)
• Cache purge webhook secrets

Even if your main WordPress install is on a traditional host like SiteGround, Kinsta, or your own VPS, if anything connecting TO that WordPress install runs on Vercel with plaintext credentials, those credentials are potentially exposed.

What every Vercel customer needs to do — priority-ordered action plan

Follow this list in order. Steps 1-3 are urgent; steps 4-6 are important but not time-critical.

Step 1: Enable two-factor authentication everywhere (5 minutes)

Before rotating anything, lock down the accounts that hold the keys to everything else:

• Vercel account — Profile icon → Settings → Authentication → enable 2FA via authenticator app or passkey
• Google Workspace / Google account — Security → 2-Step Verification → enable with authenticator app, not SMS
• GitHub / GitLab — Settings → Password and authentication → two-factor
• Your source-of-truth accounts — Stripe, Razorpay, AWS, Firebase, Supabase, OpenAI, etc.

If you're already using 2FA, check that no unfamiliar device is enrolled. Remove anything you don't recognise.

Step 2: Revoke the compromised OAuth app (2 minutes)

1. Go to Google Account → Security → Your connections to third-party apps and services
2. Search for any app referencing the compromised OAuth ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
3. If present, revoke access immediately
4. Also revoke any unfamiliar apps you don't actively use

Step 3: Rotate every non-sensitive environment variable in Vercel (30-60 minutes)

This is the core of the incident response. Open Vercel → your project → Settings → Environment Variables. For each secret-ish variable that's NOT marked with the Sensitive indicator:

1. Go to the source system (Stripe dashboard, Firebase console, AWS IAM, OpenAI platform, etc.)
2. Generate a new API key or credential
3. Copy the new value
4. Back in Vercel, Remove the old env var
5. Add Another with the same name, paste the new value, tick the Sensitive checkbox, save
6. At the source, delete the old key so it stops working

Rotate these before the end of the day, in this priority order:

1. Database credentials (connection strings with username/password)
2. Payment provider keys (Stripe, Razorpay, PayPal — live mode first, then test)
3. Cloud infrastructure keys (AWS IAM access keys, Google Cloud service accounts)
4. Authentication provider secrets (Firebase Admin SDK, Auth0, Clerk secret key)
5. Email / SMS API keys (SendGrid, Resend, Mailgun, Twilio, Vonage)
6. AI provider keys (OpenAI, Anthropic, Cohere, etc.)
7. Webhook HMAC secrets (Razorpay webhook secret, Stripe webhook secret, custom HMAC keys)
8. JWT signing secrets (for sessions, email verification, password reset tokens)
9. Third-party OAuth client secrets
10. CRM / marketing tool keys (HubSpot, ActiveCampaign, Mailchimp, SwipeOne)

Do NOT rotate:

• Any variable prefixed with NEXT_PUBLIC_ — these are inlined into the client bundle and are public by design
• Firebase client-side config (API key, auth domain, project ID) — public by design
• Analytics IDs (Google Analytics, Clarity, Mixpanel)
• Plan IDs, product IDs, or any non-secret identifiers

Step 4: Audit Vercel activity logs (15 minutes)

1. Vercel dashboard → Settings → Audit Log (on Pro+ plans) or Activity view

2. Scroll through the last 14 days

3. Look for anything unfamiliar:

   • Environment variables read, edited, or added by someone you don't recognise
   • New team members added
   • Deployment Protection tokens generated
   • Deployments triggered from unfamiliar sources
   • New integrations or OAuth apps authorised

4. If anything looks suspicious, screenshot it before anything else. That's evidence for law enforcement and for insurance, if relevant.

Step 5: Check upstream audit logs (15-30 minutes)

Your rotated credentials might have been used before you rotated them. Check the audit logs at each source:

• Stripe / Razorpay: Dashboard → Activity or Audit logs → look for API calls you didn't make, new webhooks added, refunds or payouts you didn't initiate
• AWS: CloudTrail → last 30 days → unusual regions, new IAM users, S3 bucket policy changes
• Firebase / Google Cloud: IAM & Admin → Audit Logs → new service accounts, unusual API activity
• Supabase / Databases: look for direct connections from unknown IPs, new tables or dropped tables, unusual query volume
• OpenAI / Anthropic: Usage dashboard → look for a spike in tokens you didn't generate (AI key abuse is a fast money drain)

Step 6: Set "Sensitive" as your new default

Going forward, every new env var you add to Vercel should have the Sensitive flag ticked — unless it's prefixed with NEXT_PUBLIC_ (which means it's meant to be public).

Vercel has changed the default so new env vars are Sensitive-on by default, but make it a personal habit regardless.

Special guidance for vibe-coded apps

If you've been using AI tools to generate and deploy applications, the incident has specific implications for you.

Common vibe-coder mistakes the incident amplified

1. API keys reused across projects. If your OpenAI key is in five different Vercel projects and was non-sensitive in at least one, rotate once — but update it in all five.
2. Overly permissive keys. Vibe coders often grab a top-level admin API key because the AI tool told them to. Rotate to a scoped, least-privilege key.
3. Forgotten prototypes. That project you deployed last month and forgot about? Still has your API keys. Go to Vercel → All Projects → delete anything you're not actively using.
4. Third-party AI tool integrations. If your AI coding tool (Cursor, v0, Bolt, etc.) had OAuth access to your Vercel account, review and revoke it if you're not using it.

A vibe-coder-specific checklist

• Log into every AI coding tool you've used in the last year
• Revoke any unused Vercel OAuth connections
• List every Vercel project you own (even one-off prototypes)
• Delete any project you're not actively using
• For remaining projects, rotate every non-sensitive env var
• Check OpenAI / Anthropic usage dashboards for unexplained token spikes in the last 2 weeks
• Enable spending limits on paid AI APIs so a compromised key can't burn unlimited money

Special guidance for WordPress sites hosted on Vercel

For headless WordPress, Vercel-proxied WordPress, or hybrid setups:

Priority actions

1. Regenerate WordPress application passwords. Go to WP Admin → Users → your profile → Application Passwords → revoke all existing, create fresh ones, update Vercel env vars with the Sensitive flag ticked.
2. Rotate any headless CMS tokens. WPGraphQL JWT secret, WP REST API authentication tokens, etc.
3. Check WordPress audit logs. If you have WP Activity Log installed, review the last 14 days for:
   • New admin users you didn't create
   • Unexpected plugin installs or activations
   • File edits from unfamiliar IPs
   • API key generations
4. Review WordPress user roster. WP Admin → Users → All Users. Delete any admin or editor account that doesn't belong.
5. Rotate database credentials if Vercel talks to your WordPress database directly.
6. Scan for malware. Use Sucuri SiteCheck or MalCare to scan your WordPress install for any signs of compromise.

Additional hardening for headless WordPress setups

• Enable 2FA on every WP admin account (see our WordPress security guide for detailed steps)
• Move the WordPress admin login to a non-standard URL
• Whitelist the Vercel egress IPs for any WordPress admin routes if your host supports it
• Set up a Web Application Firewall (Cloudflare, Sucuri, or Wordfence)

What Vercel did right in their response

Credit where it's due. Vercel's disclosure was faster, more detailed, and more action-oriented than most breach communications we've seen:

• Disclosure within hours of discovery, not days
• Named the specific attack vector (third-party AI tool → Google Workspace → internal access)
• Published indicators of compromise including the exact OAuth app ID, so customers could audit their own Google accounts
• Engaged Mandiant and law enforcement immediately
• Shipped a product change the same week — new env vars default to Sensitive
• Stayed factual about what was and wasn't accessed, rather than minimising or exaggerating

The incident is bad. The handling is a model for other platforms.

The bigger picture — what this tells us about supply chain security

The attack chain here is important: Context.ai → Vercel employee's Google Workspace → Vercel internal systems → customer env vars.

That's a four-hop supply chain compromise. The attacker didn't exploit Vercel directly. They exploited a third-party AI tool that a Vercel employee happened to use. This is consistent with a 2024-2026 trend in enterprise security breaches:

• 3CX (2023): North Korean group compromised an upstream software vendor, then pushed malicious updates to 3CX customers
• MOVEit (2023): A zero-day in a file transfer tool compromised thousands of downstream customers
• Okta (multiple): Attackers compromised Okta employees via customer-support channels, then pivoted to downstream customers
• GitHub Actions (recurring): Compromised third-party actions used by thousands of repos to leak secrets
• Vercel (2026): This incident

The lesson: your attack surface includes every vendor your vendors use. Enterprise customers of Vercel now need to ask Vercel which AI tools their engineers use. Customers of those AI tools need to ask the same question one level deeper. The chain goes on.

Ongoing security habits for the long term

One-time rotation isn't enough. A few habits that pay off over time:

1. Treat every env var as if it's a credit card — with its own expiry and rotation cadence. Rotate all secrets every 6 months, regardless of whether there's been a known compromise.
2. Use least-privilege keys. Instead of one "admin" API key per service, generate scoped keys that can only do what they need. If one leaks, the blast radius is small.
3. Keep an inventory. Track which env var is in which Vercel project, when it was last rotated, and where the source of truth is. A simple spreadsheet works.
4. Set spending limits on paid APIs. OpenAI, Anthropic, Twilio, SendGrid, AWS — all let you cap spend. A compromised key can burn thousands in a weekend otherwise.
5. Enable every audit log you have. Most platforms have an audit log. Most customers never look at it. Check yours monthly at minimum.
6. Subscribe to status pages and security advisories. For every critical vendor — Vercel, GitHub, Firebase, Stripe, Cloudflare — follow their status page and security disclosure feed. Most have RSS or email.

FAQ

Was my site directly hacked? No. The incident exposed environment variables to the attacker, who could then use those exposed credentials to access other services. The attacker did not deploy code, alter your site's content, or gain a shell on your servers.

Do I need to redeploy my Vercel projects? Not for this incident specifically. Once you've rotated the relevant env vars and saved them (with the Sensitive flag ticked), your next deployment picks them up. You can also manually redeploy the current production build by going to Vercel → Deployments → clicking the three-dot menu on the latest → Redeploy.

How do I know if my specific secrets were accessed? Vercel has not made individual customer data available. The safe assumption is: if it wasn't Sensitive, assume it was accessed. Check upstream audit logs (Stripe, AWS, OpenAI, etc.) for any unauthorised use in the incident window.

What if I'm on the free Hobby plan? All the guidance applies. Free-tier customers are just as affected as paid customers — the attacker didn't discriminate by plan.

Should I switch off Vercel? No. Every major cloud provider has had security incidents — AWS, Google Cloud, Azure, Cloudflare, GitHub, Netlify. The question isn't "has this vendor ever had a breach" (the answer is always yes) but "how did they handle it." Vercel's response has been exemplary: fast disclosure, detailed communication, concrete remediation, and a product fix shipped the same week.

What's the difference between a "sensitive" and "non-sensitive" env var on Vercel? Non-sensitive env vars are stored as plaintext and viewable in the Vercel dashboard by anyone with access to your project. Sensitive env vars are write-only after save — you can update them, but you can't read them back from the UI or API. The build process can still use them, but a compromised admin account or a breached Vercel system can't read the value.

Can I mark all my existing env vars sensitive retroactively? Yes, but the workflow is delete-and-re-add (you need to have the original value stashed somewhere, or regenerate it). Combine this with your rotation pass — when you paste each new secret, tick Sensitive before saving. Going forward, Vercel defaults new env vars to Sensitive, so this becomes automatic.

How often should I rotate my secrets going forward? Every 6 months as a baseline, or immediately on any suspected compromise. Critical secrets (payment provider keys, database credentials) might warrant 3-month rotation. Less critical keys (analytics service IDs, non-production API keys) can go 12 months.

Need help securing your Vercel-hosted app?

If you've been scrambling through this checklist and aren't sure what's been exposed or how to harden your setup, we offer security audits for Vercel-hosted sites — covering env var hygiene, audit log review, source-of-truth rotation, and ongoing monitoring. We've helped clients across India, the US and UK respond to supply-chain incidents since 2007. Get in touch, explore our WordPress security service, or see our ongoing care plans.