Vercel Got Breached. Here's What You Should Do Right Now.

What Happened

On April 19, 2026, Vercel disclosed that an attacker gained unauthorized access to their internal systems.

On April 20, Vercel CEO Guillermo Rauch published a detailed update. Here is what we know. A Vercel employee used an AI platform called Context.ai. That platform was breached. The attacker used that foothold to get into the employee's Google Workspace account, then escalated from there into Vercel environments.

Environment variables are encrypted at rest. But the attacker could enumerate any variable not flagged as "sensitive." Vercel is calling the attacker highly sophisticated and likely AI accelerated. Google Mandiant is now involved in the response.

Vercel says Next.js, Turbopack, and their open source projects are safe. That is Vercel's assertion. We will come back to what you should verify yourself.

What Is Confirmed vs What Is Being Claimed

This distinction matters. Do not cite unconfirmed claims in your customer or regulator communications.

Confirmed by Vercel (bulletin and CEO update, April 20)

Unauthorized access to certain internal Vercel systems.
Initial access was through Context.ai, which was itself breached.
Customer environment variables are encrypted at rest. Variables not designated "sensitive" were enumerable by the attacker.
Customer impact described as "quite limited." Vercel has directly contacted customers they have concerns about.
Next.js, Turbopack, and Vercel's open source projects are believed safe.
Google Mandiant is actively engaged. External IR firms, industry peers, and law enforcement are involved.
Vercel has shipped UI improvements around environment variable management.

Reported by third parties and the attacker. Not confirmed by Vercel.

Linear and GitHub integrations were disproportionately impacted. This comes from community reporting, notably Theo Browne on X.
Data listed for sale on BreachForums: internal database, employee accounts, GitHub tokens, npm tokens, source code fragments, activity timestamps. Listed at around two million dollars.
Actor self identifies as ShinyHunters. Other actors linked to that name have denied involvement.

Treat the unconfirmed reports as plausible and actionable for your own triage. Do not cite them in external communications until Vercel corroborates or you have independent evidence. The gap between "enumerable env vars" (confirmed) and "npm and GitHub tokens for sale" (attacker claim) is the gap that matters most for supply chain risk. Assume the worst for rotation. Stick to confirmed facts for comms.

Who Needs to Run This Playbook

Highest urgency. Run this now if any of the following are true.

You received direct outreach from Vercel.
You have or had a Vercel to GitHub integration with repository write scope.
You have or had a Vercel to Linear integration.
You store unencrypted secrets in Vercel environment variables, meaning anything not flagged as sensitive.
You publish npm packages from CI/CD that runs on or through Vercel.

Standard urgency. Any team with active Vercel projects, even marketing sites. Marketing sites hold CMS API keys, analytics tokens, and form handler webhooks. Those pivot into more sensitive systems more often than people think.

Still do it even if your projects are deleted. The question is whether secrets were ever resident in Vercel in a readable form, not whether the project still exists.

Are You Directly Exposed to Context.ai?

This matters independently of Vercel. If anyone in your organization uses Context.ai for meeting intelligence, knowledge management, CRM enrichment, or anything else, you may have your own exposure window separate from this incident.

Run these checks in parallel with everything else.

Query your SSO or identity provider (Okta, Entra, Google Workspace) for any user who has authenticated to Context.ai or a Context related OAuth app.

Search your Google Workspace admin console under Security, then Access and data control, then API controls, for context.ai or associated app IDs.

Check corporate expense and SaaS spend management tools for Context.ai subscriptions.

Review what OAuth scopes were granted. Gmail read, Calendar, Drive, and Workspace directory scopes are the high impact ones.

If you find Context.ai in your environment, revoke the OAuth grants immediately. Rotate any credentials that passed through Context.ai workflows. Monitor those users' Google Workspace accounts for the same indicators Vercel describes. Reach out to Context.ai directly for your own incident details.

Phase 0: Stop the Bleeding (First 60 Minutes)

Two goals here. Prevent new damage. Preserve evidence.

Freeze deployments. Pause auto deploys on production branches. You want to prevent an attacker modified build from shipping. You also want to stop the audit log from churning before you can snapshot it.

Disable the Vercel GitHub App. If you have automatic deployments set up, you have this app installed. Find it at https://github.com/organizations/<GitHub-Organization>/settings/installations and disable it.

Audit what the GitHub App had access to. Click Configure next to the Vercel app. Look at repository access (all repos vs selected), permissions granted, installation date, and who installed it. This tells you exactly what you need to focus on.

Snapshot the Vercel audit log immediately. Export or screenshot it before you do anything else. The retention window is short and the UI does not expose everything. Get this before you start making changes that will pollute the log. It is at https://vercel.com/activity-log.

Enable Observability Plus. Yes it is a paid feature. Yes it is annoying to have to pay for it during an incident. Enable it anyway. It extends audit log retention beyond the default which is very short. This is the right call right now.

Inventory your exposure breadth. For every Vercel team and account you control, list out the projects and linked Git repos, connected integrations (GitHub App, Linear, Slack, marketplace integrations), team members and their roles, personal access tokens and API tokens issued under the team, and deploy hooks.

Review the GitHub Organization audit log. Cover the window from April 1, 2026 through now as a conservative lower bound. Filter for the following event types.

repo.add_member, repo.add_topic
org.invite_member, org.add_member
integration_installation, integration_installation.repositories_added
protected_branch.destroy, protected_branch.update
Force pushes on any branch
New deploy keys, new webhooks, new Actions secrets or variables
New PATs, new fine grained tokens created by any org member
oauth_access.create, oauth_authorization.create

Identify your crown jewel environment variables. Anything that would let an attacker pivot elsewhere. Payment processor keys, database URLs, auth secrets, cloud provider keys, admin API keys to third party SaaS.

Open a tracking ticket and incident channel. Even if you turn out to be unaffected, the record of having run the playbook is worth having.

Do not rotate secrets yet. Do not make announcements yet. Get the snapshot first.

Phase 1: Check for Indicators of Compromise

Vercel's published IOC list is thin. They mention one Google related indicator. Here is where to find it.

Go to your Google Workspace Admin Console. Navigate to Security, then Access and data control, then API controls. Look in the accessed apps and pending apps lists.

You are looking for this OAuth app ID:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

If you find it, remove it immediately and contact an incident response partner. This is beyond a self serve fix.

As of the time of writing, Vercel has not released network IOCs like attacker hostnames or IP addresses. Keep watching the Vercel bulletin and IR firm write ups for updates. When those are published, paste them into your HTTP access logs, DNS logs, and outbound proxy logs.

Phase 2: Credential Rotation

Rotation is the single highest value action. Do it in priority order so that if something interrupts you, the most dangerous exposure has already been closed.

Tier 0. Rotate today before anything else.

GitHub Personal Access Tokens. There are two types and you need to rotate both.

Fine grained tokens: https://github.com/settings/personal-access-tokens
Classic tokens: https://github.com/settings/tokens

Then rotate all Vercel environment variables that are sensitive: https://vercel.com/all-env-vars

Tier 1. Rotate today depending on what your apps hold.

Payment processor secret keys (Stripe, Adyen, Braintree)
Authentication signing secrets (NextAuth AUTH_SECRET, NEXTAUTH_SECRET, JWT signing keys, session cookie keys, CSRF tokens)
Database connection strings with write access (DATABASE_URL, Postgres, MySQL, MongoDB, Redis with auth)
Cloud provider root or broad scope keys (AWS IAM access keys, GCP service account JSON, Azure client secrets)
Webhook signing secrets for Stripe, GitHub, Slack. Rotate at both ends.

Tier 2. Rotate this week.

Third party SaaS API keys (analytics, email providers, SMS, CRM)
OAuth client secrets for apps you own
SMTP credentials
Encryption keys for application layer crypto (with a key version bump, not a drop in replacement)
CDN purge keys, image service keys
Feature flag provider keys

Tier 3. Rotate when convenient, but still rotate.

Read only analytics tokens
Sentry and logging DSNs (rotation here is not critical unless you care about a small window of dropped events)
Public keys and anon keys (still rotate, they can reveal project existence and enable enumeration)

Things people miss every time.

.env.local committed to a private repo. Still a problem. Source code may have been exfiltrated.

Secrets in Vercel preview and development environments, not just production.

Secrets stored as Vercel team level shared environment variables.

Deploy hooks. These are full deploy triggers. Rotate them.

Vercel personal access tokens issued under your account.

GitHub Personal Access Tokens that authorized the Vercel GitHub App installation. These are separate from the app itself.

Order of operations gotchas.

Session signing key rotation invalidates all active sessions. Plan for a forced logout event. Communicate it to users before it happens.

Webhook secrets must be rotated at both ends. Update the sender first (Stripe, GitHub) to send under the new secret, then update your receiver to verify against it. Or support both temporarily during the transition.

Database credentials: create the new user first, deploy the app pointing at the new credentials, then revoke the old user. Do not do a drop in replacement or you will cause an outage.

AWS keys: create the second key, roll deployments, then delete the first. Do not deactivate and hope.

After rotating env vars, redeploy. Vercel bakes environment variables in at build time for many framework configurations. Changing the variable without a new deploy does not fully apply the change.

Check your CI secrets too. If a secret was mirrored to GitHub Actions or CircleCI, rotate the mirror.

Phase 3: Repo Level Hunting

For every repo that was connected to Vercel, diff the HEAD of your main or master branch against the last known good commit before April 1, 2026.

Look specifically for changes to these files.

package.json especially the scripts section. Look for postinstall, prepare, and preinstall changes. Attackers love hiding persistence in install hooks.

package-lock.json, pnpm-lock.yaml, yarn.lock. Unexpected dependency additions or version bumps that do not map to a corresponding package.json change.

.github/workflows/*.yml. New workflows, new run steps, new uses references with unpinned SHAs.

vercel.json. Build command changes, new rewrites or redirects that could exfiltrate traffic.

next.config.js or equivalent framework config. New headers, new rewrites pointing to unfamiliar infrastructure.

Check GitHub Actions run history for unexpected runs. Pay particular attention to manual workflow_dispatch triggers and runs from branches that no longer exist.

Look at release and tag creations you did not make.

If you publish npm packages from these repos.

This is where a Vercel initial compromise becomes a supply chain event. Even if you do not use Vercel to publish, an attacker who got your GitHub token and your publish workflow uses that token needs to be considered.

Check npm publish history for unexpected versions.

npm view <pkg> time --json

Compare the tarball of each recent version to the git tag it claims to come from. Attackers publish from a tag that does not match what is in the registry.

Audit NPM_TOKEN usage in workflows. Rotate the token. Review who had access.

Check for new maintainers added to your packages.

npm owner ls <pkg>

Unpack recent tarballs and check for post install script changes. These are invisible until you look inside the file.

If you find an unauthorized publish, report it to npm security at security@npmjs.com. Deprecate the bad version. Do not unpublish since that is time limited and breaks downstream consumers.

A note on Vercel's own packages. Vercel states Next.js and Turbopack are safe. Believe that for now but still audit your own packages. If you consume Next.js you do not need to pin to a pre incident version based on current information, but keep watching the Vercel bulletin for changes to that posture.

Phase 4: Linear Integration Review

If your team uses the Vercel to Linear integration, go to Linear workspace settings, then Security, then Audit log. Cover the same exposure window.

Look for new API keys issued, new integrations added, comments posted by service accounts, changes to webhook destinations, member invitations, and views or exports of issue data. The integration has read access to issues which often contain customer names, bug details, and sometimes credentials pasted in during debugging.

That last point is a real one. Grep your Linear workspace for these patterns: AKIA, sk_live_, ghp_, ghs_, npm_, eyJ, and BEGIN. Anything you find in there should be treated as compromised.

Phase 5: Downstream System Log Review

Rotating credentials closes the attacker's current access. But they may have already used that access. Check the consumers of your rotated secrets for signs of activity during the exposure window.

Use April 1, 2026 through now as your conservative lower bound.

AWS CloudTrail. Look for unusual API calls from the compromised IAM keys. Especially GetObject bursts against S3 buckets, CreateUser, AttachUserPolicy, and console logins from unfamiliar ASNs or countries.

Database audit logs. Unusual SELECT * on sensitive tables, large export volumes, connections from unexpected source IPs.

Stripe and payment logs. Unusual customer creation, transfer creation, API key creation.

Auth provider logs (Auth0, Clerk, Cognito, Firebase). Impossible travel logins, password resets triggered for admin users, new application registrations.

Email provider (SendGrid, Postmark). Unexpected outbound campaigns, new API keys, sender identity changes.

GitHub. Clones, fork creations, new SSH keys on user accounts with repo access.

Phase 6: Hunting for Lingering Access

Rotation closes most paths. But sophisticated attackers establish persistence before the victim rotates anything. Look for each of these actively.

New members or collaborators added to your Vercel team, GitHub org, Linear workspace, or cloud accounts during the exposure window.

New OAuth authorizations on connected SSO providers for your developers' accounts. Google Workspace, Okta, Entra ID.

Modified CI/CD configuration. Workflows that now phone home, new self hosted runners, new secrets with innocuous names.

Unexpected deployments in Vercel. Check deployment history for deploys you cannot map to a known commit by a known author.

Reverse shell indicators in serverless function logs. Base64 blobs being written or executed, unusual outbound connections from Edge or Serverless Functions.

DNS drift. New subdomains, CNAME changes, redirects added via vercel.json or framework config.

Authentication changes. MFA disabled, recovery codes regenerated, password changed without user action.

Communications

Internal. Designate an incident commander now. Run a daily standup minimum while rotation is in flight. Keep a single source of truth document covering what has been rotated, what is pending, and what has been found. Keep it out of Linear if Linear is in scope of the incident. Use a side channel.

Customer facing. Consult your legal team before saying anything externally. Notification thresholds vary by jurisdiction.

GDPR: 72 hours for notifiable breaches affecting EU residents.
Australia (NDB scheme, OAIC): notify as soon as practicable where serious harm is likely.
US: varies by state. Some states require 30 to 60 days, others require immediate notification for specific data classes.
California (CCPA): specific obligations if personal information of California residents is in scope.
SOC 2 and ISO 27001 customers: check your MSAs. Contractual notification clauses often require earlier notice than regulatory minimums.

If you have no evidence of data egress from your own systems, you may not yet have a notification obligation. "We use Vercel and Vercel had an incident" alone is usually not enough to trigger notification unless your data was materially at risk. Document your reasoning either way.

Draft these statements before you need them.

Internal all hands update
Customer facing advisory
Regulator notification template
Status page update

Public attribution hygiene. Do not restate attacker claims as fact. Link to the Vercel bulletin as the primary source. Let Vercel characterize their incident. You characterize your own exposure.

Medium Term Hardening

This incident exposes structural problems worth fixing even if you turn out to be unaffected.

Mark everything sensitive in Vercel. Migrate all secrets to the sensitive environment variable feature. Make it the team default. Train developers to flag on create.

Move to short lived credentials. Use GitHub OIDC federation to AWS, GCP, or Azure instead of long lived access keys baked into Vercel environment variables. Use cloud native secret managers accessed at runtime instead of values stored at build time.

Audit every OAuth app connected to your organization. The initial access vector here was Context.ai, an AI platform integrated via OAuth into an employee's Google Workspace. The same class of risk exists in every organization that has liberally approved SaaS and AI tool integrations. The bar for approval has dropped considerably in the past 18 months.

Pull your Google Workspace OAuth app report from Admin console, Security, API controls, App access control. Review every app with sensitive scopes (gmail.readonly, calendar, drive, admin.directory).

Do the same for Microsoft 365 via Entra ID and Enterprise applications.

Institute a quarterly review. Require security sign off for new OAuth grants that carry sensitive scopes. Consider restricting OAuth app installation to an allowlist rather than user driven approval.

Least privilege on the GitHub App. If Vercel does not need org wide repo access, restrict it to only the repos it actually deploys.

Rotate deploy hooks quarterly. Add it to a calendar.

Build secret scanning into pre commit and CI. Trufflehog and gitleaks are good options. Retroactively scan repo history too. Assume anything that was ever committed is in a clone somewhere, even if it was rotated.

Document your Vercel integration footprint as part of your SOC 2 or ISO 27001 evidence. Your enterprise customers will ask about this.

Run a tabletop in Q3. Use a hypothetical similar incident at a different platform provider as the scenario. The muscle memory generalizes. The specific provider does not matter.

Thanks for reading.

Stay safe out there.