Vercel Breach: The Context.ai Attack and What to Rotate

The Vercel breach, which Vercel calls its April 2026 security incident, started outside Vercel. According to Vercel's security bulletin, an attacker compromised Context.ai, a third-party AI tool used by a Vercel employee, and worked their way from there to customer environment variables that were not marked as sensitive. On 16 October 2026 Vercel updated the bulletin to say that all remediation actions are complete and the incident is closed. This post sets out what Vercel has said happened, who it says was affected, and the checks it recommends, all taken from Vercel's own pages.

What happened in the Vercel breach

Vercel's bulletin sets out the attack path:

1. Context.ai was compromised. Vercel says the incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee.
2. The employee's Google Workspace account was taken over. The attacker used that access to take over the employee's individual Vercel Google Workspace account.
3. That opened the employee's Vercel account. Control of the Workspace account gave the attacker access to the employee's Vercel account.
4. The attacker pivoted into a Vercel environment. From there they moved into a Vercel environment and through further systems.
5. Non-sensitive environment variables were decrypted. The attacker enumerated and decrypted environment variables that were not marked as sensitive, which Vercel describes as those that decrypt to plaintext.

Vercel says Context.ai's Google Workspace OAuth app was the subject of a broader compromise, potentially affecting its hundreds of users across many organisations. Vercel assesses the attacker as highly sophisticated, based on their operational velocity and in-depth understanding of Vercel's product API surface, and says it worked with Google Mandiant, other cybersecurity firms, industry peers and law enforcement.

On the software supply chain, Vercel says that, working with GitHub, Microsoft, npm and Socket, it confirmed that no npm packages published by Vercel were compromised and that it found no evidence of tampering.

Vercel security incident timeline

The bulletin keeps a dated log of its updates. The main entries:

Who was affected

Vercel's bulletin describes three groups:

• The first group: a limited subset of customers whose non-sensitive environment variables stored on Vercel were compromised. Vercel says it contacted them and recommended an immediate rotation of credentials.
• Additional accounts: after widening its review to more IOCs, requests to the Vercel network and environment variable read events in its logs, Vercel found a small number of additional accounts compromised as part of this incident and notified those customers.
• Separate compromises: Vercel also found a small number of customer accounts with signs of compromise that appear to be separate from the April incident and, based on its investigation, do not appear to have originated on Vercel systems. Vercel says this activity does not appear to be a continuation or expansion of the April incident, and that it contacted those accounts with corrective actions.

What to rotate and check now

The incident is closed, but the bulletin's recommendations still describe good practice for any team that keeps secrets on Vercel. Vercel stresses one point first: deleting your Vercel projects or account is not enough, because compromised secrets may still give access to production systems. Rotate them before you delete any project or account.

1. Rotate secrets that were not marked sensitive. Vercel says values that were not marked as sensitive, such as API keys, tokens, database credentials and signing keys, should be treated as potentially exposed and rotated as a priority.
2. Store secrets as the Secret type. Since 24 August 2026, you choose Config or Secret when you add an environment variable, instead of the old Sensitive toggle. The Vercel docs say Secret values are write-only after saving, so use Secret for passwords, API keys and tokens. Existing Sensitive variables are treated as Secrets without migration.
3. Turn on multi-factor authentication. Vercel recommends an authenticator app or a passkey; see its two-factor authentication docs.
4. Review the activity log. Check your account and environments for suspicious activity in the dashboard or with the CLI. The vercel activity docs show vercel activity ls --all --since 30d for team-wide events; --since also accepts an ISO 8601 date, and --limit sets how many events are returned (default 20, maximum 100).
5. Check recent deployments. Vercel says to investigate recent deployments for anything unexpected and, if in doubt, delete the deployments in question.
6. Tighten Deployment Protection. Set Deployment Protection to Standard at a minimum, and rotate your Protection Bypass for Automation tokens if you use them. Vercel notes that after you regenerate a bypass secret, you need to redeploy for your app to use the new value.
7. Check Google Workspace for the OAuth app. Vercel published one IOC and recommends that Google Workspace administrators and Google account owners check for use of this OAuth app: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com.

What Vercel changed afterwards

The bulletin lists product enhancements: better environment variable management with stronger defaults, improved safeguards and in-product education; a team-wide management and security overview of environment variables; and an easier activity log with deep links to filtered views. Vercel's changelog shows later changes along the same lines:

• 9 July 2026: build logs redact Sensitive environment variable values of 32 characters or longer, replacing them with [REDACTED] and recording the key, project and deployment in the Activity Log, never the value.
• 24 August 2026: Config and Secret types replace the Sensitive toggle. The Enforce Sensitive Environment Variables team policy is deprecated, and a new Separate Production Secret Values policy requires the Production value of a Secret to differ from the values for the same key in Preview, Development and custom environments.

The lesson for ecommerce teams

Put simply, the attack began with a compromised third-party AI tool and ended at environment variables that the platform could decrypt. Vercel's recommendations come down to keeping real secrets in write-only storage and rotating anything that was ever stored in readable form. Our own advice goes one step further: review which third-party apps hold OAuth access to your Google Workspace, not only the one app Vercel named. Our post on the Railway security breach covers a separate incident at another hosting platform where environment variables were also at the centre, and if you run Next.js on Vercel, our guide to checking whether your Next.js version is vulnerable covers the framework side.