# Vercel's April 19 Security Incident: What Customers Should Do > Canonical: https://juliet.sh/blog/vercel-april-2026-incident-what-customers-should-do > Published: 2026-04-19 > Author: Juliet Security Team > Tags: supply-chain, vercel, environment-variables, secrets-management, incident-response > Read time: 6 min read _Vercel's April 19 security incident: which env vars are exposed, which are safe, and what every Vercel customer should rotate tonight._ --- On the morning of April 19, 2026, Vercel [disclosed a security incident](https://vercel.com/kb/bulletin/vercel-april-2026-security-incident) — being called the "Vercel hack" or "Vercel breach" in social and trade press — involving unauthorized access to certain internal Vercel systems. Vercel states a "limited subset of customers" were impacted, that affected customers are being notified directly, and that services remain operational. If you deploy anything via Vercel, the incident-response window is right now, and the immediate question is simple: **which of your environment variables are marked sensitive, and which aren't?** The answer decides what you need to rotate tonight. ## What's confirmed vs what's reported The official bulletin is deliberately sparse, so it's worth separating the two. **Confirmed by Vercel's security bulletin:** - Unauthorized access to certain internal Vercel systems - Limited subset of customers impacted; Vercel is engaging with them directly - Incident-response experts retained; law enforcement notified - Customers are recommended to review their environment variables and use the sensitive environment variable feature **Reported but not yet in the bulletin**, via [Theo (@theo)](https://x.com/theo/status/2045870216555499636) citing his own sources: - Primary victim was Vercel itself — internal Linear and GitHub took the bulk of the impact - Environment variables marked sensitive are safe (Vercel's sensitive flag encrypts them at rest and prevents read-back via REST) - Non-sensitive environment variables should be rolled out of precaution None of that second block is Vercel-official yet, but the recommended mitigation lines up with Vercel's own bulletin: **assume non-sensitive env vars are exposed and rotate them.** We'll update this post as Vercel publishes more detail. ## Why the sensitive flag matters The `sensitive` flag on a Vercel environment variable is architectural, not a UI hint. Per [Vercel's documentation](https://vercel.com/docs/environment-variables/sensitive-environment-variables), variables marked sensitive: - Are encrypted at rest and decrypted only at build or runtime - Cannot be read back via the REST API or the dashboard once set - Don't appear in deploy logs, preview URLs, or build output Variables NOT marked sensitive: - Are stored in a form readable through the dashboard and REST API - Can surface in build logs and deploy previews - Are exposed to anyone with access to the project on the team If an attacker breached internal Vercel systems, the most plausible exposure surface is non-sensitive environment variables — readable through Vercel's internal tooling by design. That's why the recommended mitigation is to rotate the non-sensitive ones specifically. ## Who is affected Vercel is notifying directly impacted customers. If you haven't been notified, you're most likely not in the directly-impacted set. But the precautionary posture is: **if any secret in a Vercel project is stored as a non-sensitive env var, rotate that secret tonight.** "Not being on Vercel's list" and "having leaked secrets" aren't the same thing. Credentials worth treating as potentially exposed include: - Database connection strings (Postgres, MongoDB, Supabase, Redis) - API keys for third-party services (Stripe, OpenAI, Anthropic, SendGrid, etc.) - JWT signing secrets - Webhook signing secrets - Feature-flag provider keys - Analytics / logging API tokens - Any long-lived credential your Vercel project has stored ## How to check and rotate ### 1. Audit env vars in the Vercel dashboard Open each project → **Settings** → **Environment Variables**. For each entry, check the sensitive toggle. - **Sensitive: ✓** → Safe per Vercel's architecture. No action needed. - **Sensitive: ✗** → Treat as exposed. Rotate, then re-set with the sensitive flag enabled. ### 2. List env vars programmatically The dashboard is fine for one project. If you have a dozen, use the Vercel CLI: `vercel env ls ` That returns the names and flags (but not the values) for the current project. Anything marked "Plain Text" is a rotation candidate. For automation across many projects, the [REST API](https://vercel.com/docs/rest-api/endpoints#list-environment-variables) returns the same shape. A few lines of shell or Node can enumerate every project in a team faster than the dashboard UI. ### 3. Rotate each non-sensitive secret at the source For each exposed credential: - Rotate it at the issuing service (database, API provider, etc.) - Update the Vercel env var and enable the sensitive flag this time - Redeploy - Confirm the old credential is **revoked**, not just replaced Rotating without revoking leaves the old credential valid — and the premise of this exercise is that a stolen copy may exist. ### 4. Check your Vercel access logs Vercel's team-activity log shows team-member actions. Look for unfamiliar access or unexpected API usage in the period leading up to disclosure. Anything unexplained is worth sharing with Vercel's support team if they reach out. ## Longer-term hardening - **Default everything to sensitive going forward.** The sensitive flag is the correct default for any string you wouldn't paste in a public channel. The "plain text" default for new env vars is a footgun worth disarming. - **Prefer short-lived credentials over static env vars.** OIDC federation with your cloud provider, per-deploy tokens, or runtime-injected credentials from a secrets broker all cut the rotation burden during incidents like this. - **Limit who has env var read access.** Vercel team roles control who can read non-sensitive env vars from the dashboard. Audit your team list during this incident and trim anyone who doesn't need production access. - **Monitor for use of rotated credentials.** Set an alert on your upstream services (database, cloud IAM, API providers) for authentication attempts using the now-invalid credential. If one shows up after rotation, you know the stolen copy was real. ## The bigger picture This is the third CI/CD-adjacent security incident we've written up in six weeks: [Trivy](/blog/trivy-supply-chain-compromise-what-kubernetes-teams-need-to-know), [axios on npm](/blog/axios-npm-supply-chain-compromise-finding-it-in-your-kubernetes-clusters), now Vercel. The pattern is bigger than any one vendor: - Developer platforms and security tools run with privileged access to customer credentials - Their internal systems — Linear, GitHub, Slack, internal dashboards — aggregate sensitive data across the customer base - When those internal systems get breached, the [blast radius](/kubernetes-security/blast-radius) is every downstream customer whose secrets touched the platform The defensive posture is the same each time: know which secrets touched which systems, keep credentials short-lived, and treat every platform you depend on as potentially breached. "If this vendor got compromised tomorrow, what's exposed?" is a question worth answering before the news arrives, not after. That's the kind of reachability question [we built Juliet to answer](https://juliet.sh/pricing) for Kubernetes clusters — mapping credentials, workloads, and network paths into one graph so "which of our secrets could an attacker actually reach through this?" has an answer in minutes rather than a week. ## Frequently asked questions ### Was Vercel hacked? Yes. Vercel [publicly disclosed](https://vercel.com/kb/bulletin/vercel-april-2026-security-incident) a security incident on April 19, 2026 involving unauthorized access to certain internal systems. The incident is being called the "Vercel hack" or "Vercel breach" in social and trade press. A limited subset of customers were impacted and are being notified directly by Vercel. ### Should I rotate all my Vercel environment variables? No. Vercel's sensitive environment variables are architecturally protected — encrypted at rest and not readable via the REST API or dashboard once set. Rotate only env vars **not marked sensitive**, and enable the sensitive flag on everything going forward. ### Are Vercel's sensitive environment variables safe in this breach? Per Vercel's documentation and reporting from Theo (@theo)'s sources, yes. Sensitive env vars are encrypted at rest and can't be read back via any REST call. If you've used the sensitive flag correctly, those values should be protected. ### What customer data was stolen in the Vercel hack? Vercel has confirmed only that a "limited subset of customers" were impacted and hasn't released specifics about data. Impacted customers are being notified directly. If Vercel's security team hasn't contacted you, you're likely not in the directly-impacted set — but the precautionary posture is still to rotate non-sensitive env vars. ### Is Vercel still safe to use? Vercel's services remain operational per their bulletin. Reporting indicates the incident affected internal systems (reportedly Linear and GitHub), not Vercel's production hosting infrastructure. Deployments, DNS, and runtime are not affected by the disclosed incident. ### How do I mark an env var as sensitive in Vercel? In the Vercel dashboard: open your project → **Settings** → **Environment Variables**. When adding or editing a variable, enable the "Sensitive" toggle. Note: once marked sensitive, the value can't be read back in the dashboard — only updated or deleted. Plan your rotations accordingly. Questions or need help assessing exposure? Reach us at [contact@juliet.sh](mailto:contact@juliet.sh). We'll update this post as Vercel's bulletin gets more detailed.