Vercel published a security bulletin on April 19 confirming a breach of its internal systems. On April 20, CEO Guillermo Rauch followed up with the root cause: a Vercel employee used a third-party AI tool called Context.ai. Well, this tool got breached. The attacker pivoted from there into the employee's Vercel Google Workspace account, and from there into Vercel environments and environment variables that weren't marked as "sensitive." Is this the customer fault? (jk)
Vercel says a "limited subset" of customers were directly impacted and have been contacted. They also say Next.js, Turbopack, and their other open-source projects have been analyzed and are believed safe.
That's the facts. Now the honest part: if you deploy on Vercel, don't wait for an email. Rotate first, ask questions later.
The Vercel breach checklist
1. Rotate every environment variable that wasn't marked as "sensitive" in Vercel.
Do this first if you do nothing else. Vercel's sensitive environment variable feature encrypts values at rest and hides them from the dashboard after creation. Everything else - the default - was readable by anyone with access to that employee's Google Workspace session. Assume those values leaked. Payment processor keys, database URLs, auth secrets, cloud provider keys, admin API tokens to third-party SaaS. Rotate all of it.
2. Review your GitHub organization audit log.
If your Vercel account is connected to GitHub (it almost certainly is), pull the audit log for April 1 through today. Look for unexpected OAuth grants, new deploy keys, workflow edits, branch protection changes, or pushes from unusual IPs. The community-maintained IR playbook has a solid filter list.
3. If you use the Vercel ↔ Linear integration, check Linear's audit log too.
Linear issues are where people paste stack traces, database URLs, and occasionally plaintext secrets while debugging. The integration has read access to issues. Workspace settings → Security → Audit log.
4. Audit any npm package you publish from a Vercel-connected workflow.
Vercel says their own packages are clean. That's their release path, not yours. If you use Vercel's build environment to run npm publish or push to a registry, treat any package published in the exposure window as suspect until you've diffed it.
5. Don't skip the boring step: inventory your exposure.
For every Vercel team you control, list the projects, the connected Git orgs, the integrations, and the humans with access. Half the pain of incident response is discovering on day three that there was a second team nobody remembered.
The part nobody wants to talk about
The attack didn't start at Vercel. It started at Context.ai, an AI tool a single employee had connected to their work account. They also posted about it. This is how modern breaches happen. You don't get popped through your WAF. You get popped because someone on your team authorized an OAuth grant to a YC-stage AI startup that had one security engineer and a Notion doc for an incident response plan.
There's no EU-vs-US angle here. European PaaS vendors have employees too. Employees use AI tools. The same thing could happen to Scalingo, Clever Cloud, or us at orkestr.
What matters is:
- How much blast radius does one compromised employee account actually have?
- Are production secrets readable from a dashboard, or are they sealed?
- How fast does the vendor tell you, and how specifically?
Vercel's bulletin on April 19 was terse to the point of unhelpful. The detail came from press reporting and a follow-up from the CEO a day later. "We recommend reviewing environment variables" isn't incident communication. It's a legal posture. You should expect better from anyone you hand your deploy keys to — us included.
Whatever platform you're on: rotate your secrets today. Mark them sensitive. Cut the SaaS integrations you're not using. And write down who on your team has production access, because there will be a next one.
Top comments (0)