Vercel Stored Your Secrets in Plaintext and Called It a Feature

Vercel got breached. The attacker was inside for approximately two months before detection. They enumerated and decrypted customer environment variables — API keys, database passwords, signing keys, tokens — for every project that didn't use Vercel's optional "sensitive" flag.

The attack chain: a third-party AI tool called Context.ai was compromised. The attacker used that foothold to take over a Vercel employee's Google Workspace account. From there, they pivoted into Vercel's internal systems. Then they started reading secrets.

The data is now allegedly being offered on BreachForums for $2 million.

The "sensitive" checkbox that wasn't default

Here's the part that matters.

Vercel has two types of environment variables. Regular ones, which are "encrypted at rest" but can be decrypted and read by Vercel's systems. And "sensitive" ones, which use additional encryption that Vercel says prevents even internal access.

The attacker could read all the regular ones. Only the "sensitive" ones were protected.

The problem: "sensitive" was opt-in. Not the default. Every developer who set DATABASE_URL or STRIPE_SECRET_KEY or JWT_SIGNING_KEY without checking a box — and that's most of them — had those values sitting in a format that an attacker with internal access could decrypt.

Vercel's post-breach guidance: "Enable the sensitive environment variable feature for encrypted storage." Translation: the encryption you assumed was protecting your secrets wasn't actually protecting them from us, or anyone who got into our systems.

Two months of dwell time

The initial compromise happened in February 2026. Vercel published its first security bulletin on April 19. That's roughly two months of an attacker having access to internal systems.

Vercel's own security team described the attacker as "highly sophisticated based on their operational velocity and in-depth understanding of Vercel's product API surface." When the company hosting your infrastructure says the attacker understood their systems better than expected, that should give you pause.

During those two months, the attacker had time to enumerate every accessible environment variable across affected customer projects. Time to exfiltrate. Time to sell.

The OAuth supply chain

The entry point wasn't even Vercel's own code. A Vercel employee authorized Context.ai — an AI productivity tool — via Google OAuth. When Context.ai was compromised, the attacker inherited every permission that OAuth grant provided.

This is a pattern that keeps repeating. Organizations carefully lock down their primary authentication, then hand out OAuth tokens to third-party tools that have their own, often weaker, security posture. One compromised app in the chain and the attacker inherits your employee's access.

The compromised OAuth App ID is public: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. If your organization authorized this app, revoke it now.

What you should do

If you deploy on Vercel:

• Rotate every environment variable immediately — don't wait to determine if you were "affected"
• Enable the sensitive flag on all environment variables going forward
• Audit your Google Workspace OAuth app permissions and revoke anything you don't actively use
• Review Vercel deployment logs for unexpected changes during February-April 2026
• Check downstream services (databases, payment processors, APIs) for unauthorized access using the credentials that were stored in Vercel

The real lesson

Vercel's architecture stored customer secrets in a way that internal access could decrypt them. They offered a stronger option, but didn't make it the default. For two months, nobody noticed an attacker reading those secrets.

This is the problem with "trust us" security. Vercel encrypted your environment variables at rest — technically true. But they held the decryption keys. When their systems were compromised, so were your secrets.

The alternative is zero-knowledge architecture, where the service provider mathematically cannot decrypt your data. Not "chooses not to" — cannot. No amount of internal compromise, no rogue employee, no sophisticated attacker who lives in your infrastructure for two months can read what the server never had the keys to decrypt.

Vercel is asking customers to check a box to opt into real encryption. The question worth asking: why wasn't that the only option from the start?