Vercel confirmed a security incident this month, with threat actors claiming to be selling stolen data on underground markets. BleepingComputer reported on the breach as the Hacker News thread climbed past 487 points and 293 comments, which tells you how much of the developer community has a stake in what Vercel stores.
The story is worth examining not just as a post-mortem on one company, but as a reminder of what you actually hand over when you connect a deployment platform to your repositories.
What Vercel Holds
Vercel’s value proposition is that it takes your code and makes it run. The flip side of that convenience is a substantial trust relationship. By the time you have a production deployment on Vercel, the platform has likely touched:
- Environment variables and secrets. Vercel stores these encrypted at rest and injects them at build and runtime. Your
DATABASE_URL,STRIPE_SECRET_KEY,OPENAI_API_KEY, and anything else you’ve defined in the project dashboard lives there. - Source code access. GitHub, GitLab, and Bitbucket integrations give Vercel read access to your repositories at minimum, often broader OAuth scopes.
- Build logs. These frequently contain more than people expect: package version output, dependency resolution logs, and occasionally secrets that get printed by accident.
- Customer metadata. Team membership, billing records, domain configurations, and deployment history.
- Tokens and webhooks. Integration tokens used to post deployment status back to GitHub, Slack webhooks for notifications, and so on.
That is a wide blast radius. A breach that exposes environment variables is not just a Vercel problem; it becomes a database breach, a payment processor breach, and an API key rotation emergency across every service those variables authenticate against.
The CI/CD Trust Problem
This is not the first time a deployment or CI/CD platform has been the pivot point. CircleCI disclosed a breach in January 2023 where an engineer’s laptop was compromised via malware, ultimately allowing attackers to exfiltrate environment variables and tokens from customer projects. The company told users to rotate every secret stored in CircleCI immediately. Travis CI had a different but related problem in 2021 when a vulnerability in their API exposed environment variables for public and private repositories, including tokens for open-source projects like Ruby, PHP, and Python packages.
The pattern is consistent: the CI/CD layer aggregates secrets from many organizations, which makes it a high-value target. Attackers do not need to compromise each organization individually if the platform connecting them all can be breached once.
Vercel’s architecture is somewhat different from self-hosted CI runners. Builds run in isolated environments, but the secrets store is centralized and managed by Vercel. When you set an environment variable through the dashboard or the Vercel CLI, it gets encrypted and stored server-side. The encryption is only as good as the key management, and the access controls are only as good as the authentication layer protecting them.
What the Actual Risk Looks Like for a Typical Project
For a small personal project with a hobby API key or two, the risk is annoying but contained. For a production SaaS with a few dozen environment variables pointing at real customer data, it is a different situation entirely.
Consider a Next.js application deployed on Vercel with a typical production config:
# Typical Vercel env variables for a production app
DATABASE_URL=postgresql://user:password@host/db
NEXTAUTH_SECRET=...
STRIPE_SECRET_KEY=sk_live_...
SENDGRID_API_KEY=SG....
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...If those variables were exfiltrated, you are looking at a database dump, unauthorized charges via the Stripe key, emails sent from your domain, and potentially full AWS account access. None of that requires any further exploitation of your own codebase. The attacker already has everything they need.
The time-to-damage for leaked live credentials is measured in minutes, not days. Automated credential scanning tools constantly probe for newly exposed secrets across paste sites and breach data dumps.
What You Can Actually Do
The uncomfortable answer is that you cannot fully eliminate this risk while using a managed deployment platform. You are exchanging some security control for developer convenience, and that is often a reasonable trade. But you can reduce the blast radius significantly.
Use short-lived credentials wherever possible. AWS IAM roles with short token lifetimes through OIDC federation are better than long-lived access keys. GitHub Actions and Vercel both support OIDC. If a token expires in an hour, an attacker who exfiltrates it has a narrow window.
Scope your secrets tightly. A Stripe restricted key that can only create payment intents is better than the full secret key. A database user with read-only access to the tables your app actually queries is better than a connection string with superuser privileges. These principles are obvious but frequently ignored under time pressure.
Use a secrets manager instead of platform env vars for the most sensitive values. Tools like HashiCorp Vault, AWS Secrets Manager, or Doppler let your application fetch secrets at runtime rather than having them baked into the deployment environment. Vercel itself documents integration with secrets managers. If Vercel’s env var store is compromised, your application’s runtime secret fetching from an external vault is a separate trust boundary the attacker would need to cross.
Audit your OAuth scopes. When you connect Vercel to GitHub, check what permissions you actually granted. Repository read access for deployments is different from full organization write access. Reducing scope limits what is available if the integration token is abused.
Have a rotation runbook. If you had to rotate every secret your Vercel projects use in the next two hours, could you do it? The answer for most projects is a painful no. Writing that runbook before you need it, and knowing which services support automated rotation, is time well spent.
The Broader Vendor Dependency Problem
Vercel is not uniquely risky. GitHub Copilot knows your code. Datadog and similar observability platforms receive your logs, which may contain more than intended. Your Heroku or Railway deployment has your database URL. Your Render instance has your API keys. Every managed service in your stack is a potential pivot point.
The answer is not to run everything yourself on bare metal, because that introduces different and often larger security risks for teams without dedicated infrastructure expertise. The answer is to understand what each vendor holds, assume any of them could be breached, and architect your secrets management so that a breach of one vendor’s environment variable store does not give an attacker the keys to everything else.
The Vercel incident is a good prompt to audit your own projects. Look at your env var list in the Vercel dashboard right now and ask yourself what an attacker could do with each one. If the answer to any of them is “quite a lot,” that is the one to address first, regardless of whether your platform has been breached today.
Deployment platforms have made shipping software dramatically easier. They have also become load-bearing pieces of the security posture of every project they host. That is worth taking seriously.