The “Non-Sensitive” Env Var Myth: What the Vercel Breach Actually Exposed

What happened at Vercel

On April 19, 2026, Vercel published a security bulletin disclosing unauthorized access to internal systems. The attack chain is worth understanding precisely, because it follows a pattern that is going to become more common as AI tooling proliferates.

Vercel engaged Mandiant and law enforcement. Services stayed operational. Affected customers were contacted and advised to rotate credentials, review activity logs, and enable sensitive variable protection. The right response — but it came after the exposure, not before.

Why “non-sensitive” is a broken security category

Every platform that handles secrets eventually creates a two-tier system: sensitive things and everything else. It feels like a reasonable UX decision. Marking every env var as sensitive is noise; marking nothing is negligent. A checkbox lets developers express intent.

Here are the “non-sensitive” variable categories that consistently appear in post-breach forensics:

None of these contain a “secret” in the traditional sense. All of them contribute to a successful attack. The “sensitive” checkbox creates a mental model where unmarked vars are implicitly safe. They are not.

The attack vector you need to think about: AI tooling as a supply chain threat

The initial compromise in Vercel's breach wasn't a phishing email or a leaked password. It was a third-party AI productivity tool — Context.ai — that had OAuth access to an employee's account.

This is the pattern to watch. AI tools in 2026 almost universally request broad OAuth scopes: “Read your email,” “Access your calendar,” “View your Google Drive.” When one of those tools is compromised — whether through a vulnerability in the tool itself, a supply chain attack on its dependencies, or a breach of the tool vendor — every account that granted it OAuth access becomes a pivot point.

What a CodeSlick scan finds in a typical Next.js/Vercel project

We ran CodeSlick's secrets detector across a representative Next.js project scaffolded from create-next-app with a standard auth + database setup. These are the patterns that appear before deployment — in source code, config files, and committed environment examples — that feed directly into the attack surface the Vercel breach exploited.

// lib/db.ts
const client = new PrismaClient({
  datasources: {
    db: {
      url: "postgresql://admin:S3cr3tPass@prod-db.internal:5432/myapp"
    }
  }
})

// lib/auth.ts
const secret = "jwt_secret_hardcoded_during_dev_replace_me"  // never replaced

// .env.example (committed to git — real values left in by mistake)
DATABASE_URL=postgresql://admin:S3cr3tPass@prod-db.internal:5432/myapp
STRIPE_SECRET_KEY=sk_live_abc123realkey

// Inadvertently exposing a server-side key to the browser bundle
const stripe = new Stripe(process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY!)
//                                   ^^^^^^^^^^^^ wrong prefix

// OpenRouter / AI provider key leaked client-side
const openai = new OpenAI({ apiKey: process.env.NEXT_PUBLIC_OPENROUTER_KEY })

// Found in: lib/github-app.ts
const privateKey = `-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA2a2rwplBQLF29amygykEMmYz0+Kcj3bKBp29S2rWPHO...
-----END RSA PRIVATE KEY-----`

The defense: catch secrets before they ever reach a platform

Vercel's breach happened at the platform level — credentials that were already deployed. Platform-level protections (sensitive flags, access controls, audit logs) are necessary but insufficient. The problem starts in the developer's local environment, before a commit is ever made.

CodeSlick's CLI pre-commit hook blocks the commit if secrets are detected. No network call. No CI round trip. The secret never reaches your repository, your platform, or any vendor's storage — regardless of how their “sensitive” classification works.

# Install the CodeSlick CLI
npm install -g @codeslick/cli

# Initialize pre-commit hook in your repo
codeslick init

# The hook now runs on every git commit:
# ✓ 38 secret patterns (zero false positives on placeholders/test values)
# ✓ All 5 languages: JavaScript, TypeScript, Python, Java, Go
# ✓ Blocks commit if secrets found — with exact line numbers and remediation guidance
# ✓ Pass/fail thresholds configurable via .codeslick.yml

$ git commit -m "add db connection"

CodeSlick pre-commit check...

  CRITICAL  lib/db.ts:14
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Hardcoded database credentials detected
  Rule: SEC-CREDS-001 · CVSS 9.1

  Found: postgresql://admin:S3cr3tPass@prod-db.internal:5432/myapp
  Fix:   Replace with process.env.DATABASE_URL

  HIGH      .env.example:3
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Real API key detected in committed .env file
  Rule: SEC-CREDS-007 · CVSS 8.2

  Found: STRIPE_SECRET_KEY=sk_live_...
  Fix:   Use a placeholder value: STRIPE_SECRET_KEY=sk_live_YOUR_KEY_HERE

2 secret(s) found. Commit blocked.
Run `codeslick fix` to apply suggested remediations.

The lesson: platform labels are not a security control

Vercel will improve. They'll add better defaults for sensitive flags, tighter OAuth scope review for third-party tools, and more granular access controls. Those are good changes. They won't solve the underlying problem.

The underlying problem is that credentials — real credentials — end up in places they shouldn't. They end up in source files during development. They end up in .env.example when someone copies a real value for reference. They end up as “non-sensitive” env vars because the developer didn't recognize the risk, not because the value was actually low-risk.

The control that actually prevents platform-level exposure is keeping secrets out of the platform in the first place — or ensuring that anything that reaches the platform is either rotatable in under five minutes or genuinely non-sensitive (think: public feature flags). That means catching them at the source: in your editor, in your pre-commit hook, in your PR check.