Major Vercel Breach Disclosed — Rotate Every Token Now

Major Vercel Breach Disclosed — Here Is What to Do Today

This is one of the most consequential supply chain disclosures of 2026 so far. Vercel published an incident bulletin describing unauthorized access to a subset of customer accounts, with plaintext environment variables — API keys, database credentials, signing keys — exposed for a defined set of projects. The bulletin has been updated multiple times between April 19 and April 24, 2026 as the scope of the investigation continues to expand.

If any part of your stack ships through Vercel, treat this as an active security incident, not a headline to skim past. The next 48 hours decide whether a leaked credential ends as a quiet rotation or as a follow-on incident inside a connected database, cloud account, or SaaS provider. Even if you have not received an individual notification from Vercel, the responsible default is to act now and verify later.

What Happened

The chain that reached Vercel did not start at Vercel. The first compromise was a third-party AI tool called Context.ai that a Vercel employee used as part of normal day-to-day work. The attacker compromised that tool, and from there pivoted into the employee's individual Google Workspace account.

With Workspace access, the attacker reached connected internal systems at Vercel and exfiltrated data linked to a defined set of customer projects. Vercel's bulletin highlights two things about the actor: high operational velocity between stages, and detailed knowledge of the Vercel product API surface. That combination is the signature of a prepared adversary, not an opportunistic scan-and-grab.

This pattern — SaaS AI helper → corporate identity → product platform — is now a familiar supply chain shape. Most teams are not yet treating their AI tooling as part of the identity perimeter, and that gap is what the attacker monetized.

Timeline as Published in the Vercel Bulletin

The bulletin records the following update timestamps verbatim:

• April 19, 11:04 AM PST — Vercel publishes an indicator of compromise (IOC) to support the wider community.
• April 19, 6:01 PM PST — Vercel publishes information about the origin of the attack.
• April 20, 10:59 AM PST — further clarification of the definition of compromised credentials.
• April 20, 5:32 PM PST — Vercel validates that npm packages are not compromised and adds guidance for multi-factor authentication.
• April 22, 7:58 PM PST — findings from continued investigation are published with additional details.
• April 23, 9:54 AM PST — further clarification of investigation findings.
• April 24, 4:22 PM PST — bulletin marked as "no updates published"; document moves to an ad hoc update cadence.

The bulletin lists "Last updated April 24, 2026." Investigation continues with Google Mandiant, GitHub, Microsoft, npm, and Socket. No specific individual customer notification dates are published in the bulletin.

For affected customers, expect more notifications as scope clarifies. For unaffected customers, do not assume the bulletin is final — the practical posture is to rotate now and not wait for a personal email from your platform.

What Was Exposed

The exposure is bounded and specific in the bulletin, but the risk it creates is broad:

• Plaintext environment variables stored as non-sensitive on affected projects: API keys, service tokens, database connection strings, signing keys, webhook secrets, OAuth client secrets, and similar values.
• Encrypted (sensitive) environment variables were not exposed, according to Vercel.
• npm packages associated with affected accounts were checked and confirmed not tampered with.

The risk is concentrated in any secret that lived in a project's plaintext environment variable list, even if you originally classed it as "low value." A read-only token to one service plus a publishable API key from another can chain into a far worse outcome than either looks like in isolation. The way to think about plaintext env vars right now is: every value in that list is a credential that an unknown party may already hold.

Why Plaintext Env Vars Were the Target

Build platforms made plaintext environment variables convenient because they are the simplest possible developer experience: paste a value into a field, ship code, move on. The same convenience created a permanent on-platform store of long-lived credentials, often with no rotation policy and no central inventory. Once an attacker reaches the platform's internal systems, that store is essentially a key ring with everyone's keys on it.

Encrypted variables on the same platforms typically use envelope encryption with keys held outside the build environment. That extra layer is exactly what limited the blast radius of this incident.

Who Should Act

If your project is hosted on Vercel, assume the value of every plaintext environment variable is untrusted until rotated. The blast radius is wider than the explicitly affected accounts because tokens leak laterally — a database credential exposed in one project may grant access to data shared with another, and a CI token exposed in one repository may unlock deployment in several.

This is not a "wait until Vercel emails me" moment. The cost of rotating a few dozen tokens is hours of engineering time. The cost of waiting for confirmation that you were affected is the same rotation, plus whatever the attacker did with the credentials in the meantime.

Action Plan for the Next 48 Hours

1. Inventory every plaintext environment variable across every Vercel project. Export the list and treat it as a credential register, not a configuration list.
2. Rotate at the source first. Replace the secret in the upstream service (the database, the cloud provider, the SaaS API) before pushing the new value to Vercel. Rotating only on the platform leaves the old credential live somewhere else.
3. Enforce multi-factor authentication for every team member with access to the Vercel dashboard, the linked Git provider, and any cloud account whose credentials lived in environment variables. Require hardware keys or platform authenticators where possible.
4. Audit deployment activity for unexpected builds, redeploys, environment changes, branch protection changes, and new team invites in the period leading up to April 19, 2026 and after. Look for build logs that reference unfamiliar destinations, new outbound endpoints, or modified install scripts.
5. Audit downstream services for unauthorized API calls, anomalous data egress, new IAM principals, new webhook subscriptions, and new outbound rules. The Vercel bulletin does not publish a confirmed start date for the compromise window, so the safe approach is to audit a broad window leading up to and including the bulletin period. Cloud audit logs (CloudTrail, Cloud Audit Logs, Activity Log) are the right place to start.
6. Move secrets out of plaintext wherever possible. Migrate to Vercel's sensitive (encrypted) variables, a managed secret store such as AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, or HashiCorp Vault, or a runtime injection pattern that avoids storing the secret in the build configuration at all.
7. Enable Deployment Protection on production environments and rotate any tokens tied to that protection layer. Review who currently bypasses it.
8. Review your AI tool inventory. List every AI tool with access to employee mailboxes, calendars, documents, code, or production systems. Re-scope or revoke access where the value of the tool does not justify the access it holds.
9. Communicate internally. Mark the rotation as a tracked task with an owner, a deadline, and a verification step. Untracked rotations get partially completed and quietly forgotten.

Long-Term Hardening

A rotation cycle solves the immediate exposure. The longer-term fix is to remove the conditions that made the exposure possible:

• Move from "secret in env var" to "identity in build." Cloud providers offer workload identity federation that lets a build environment exchange a short-lived identity token for cloud credentials at runtime, with no long-lived secret stored on the platform.
• Adopt secret managers with rotation built in. Managed secret stores can issue short-lived database credentials and rotate API keys on a schedule. The right metric is "how many of our credentials live longer than 90 days," and the goal is to drive that number down.
• Treat AI tooling as identity. The AI tools your team uses with corporate accounts are part of your identity perimeter. Inventory them, scope their access, review them on the same cadence as SSO connectors, and assume they will be a future entry point.
• Track plaintext-to-encrypted migration. Make "no new plaintext env vars in production" a default rule, and run a recurring sweep to flag plaintext variables introduced after the cutoff.
• Practice the rotation. A rotation that has been run as a drill takes hours. A rotation that has only been documented takes days under pressure. Run a quarterly rotation drill against a non-production environment.

Lessons for Anyone Running on a Hosted Platform

The incident is a clean example of a third-party AI tool becoming a supply chain entry point, and the lessons generalize beyond Vercel customers:

• The perimeter is wider than your platform vendor list. Any third-party tool that authenticates to a corporate account can become an entry point. The security review for those tools needs to be at least as careful as for SSO and IdP integrations.
• Plaintext environment variables in build platforms are not a long-term storage strategy for credentials. Move sensitive values into a dedicated secret manager and pull them at runtime.
• Convenience and security trade off in real time. A workflow that lets a developer ship a new integration in five minutes by pasting a token will, at scale, become a list of tokens that someone must one day rotate in an emergency. Choose the secret pattern with that day in mind.
• Disclosure timing matters. Vercel published the bulletin and continued updating it as scope expanded, which is the right model. Plan your own disclosure pattern before you need it, not while you are using it.

Reference

The original Vercel bulletin is available on the Vercel knowledge base and is being updated as the investigation progresses. Affected customers receive direct notifications. If you have not been contacted, the recommended posture is still to rotate plaintext environment variables and treat the next deploy as an opportunity to remove credentials from the build platform entirely.