Vercel Redacts Build-Log Secrets After Its April Breach
Vercel now masks long Sensitive environment variable values in build logs, closing a leak path the April Context.ai breach didn't touch.

Vercel started redacting Sensitive environment variable values from build logs on July 9, 2026, replacing any value 32 characters or longer with [REDACTED] wherever it would otherwise print during a build (Vercel changelog, July 9, 2026). It’s a narrow fix, but it lands three months after an incident that turned Vercel’s Sensitive/regular env-var split into the difference between a contained breach and a much worse one.
What changed
The redaction only applies to variables explicitly marked Sensitive in a project’s settings, and only once a value is 32 characters or longer (Vercel changelog). Two system variables, VERCEL_AUTOMATION_BYPASS_SECRET and VERCEL_OIDC_TOKEN, are always redacted regardless of length. Vercel’s Activity Log now records that a redaction happened, plus the variable’s key, project and deployment, but never the value itself. The scope stops at build logs: runtime logs, values baked into a NEXT_PUBLIC_ bundle, or secrets committed to source are untouched by this change (Vercel docs, Sensitive environment variables).
Sensitive variables already got separate handling before this update: Vercel stores them encrypted at rest, hides the value from the dashboard after it’s saved, and won’t let you edit the variable’s key once set. A regular, non-Sensitive variable gets none of that. It’s stored in a readable format and visible to anyone with project access.
Why now
That Sensitive/regular split is what limited the damage in Vercel’s April 2026 security incident. Attackers compromised Context.ai, a third-party AI tool used by a Vercel employee, pivoted through a Google Workspace OAuth takeover into that employee’s Vercel account, and from there enumerated and decrypted environment variables across a subset of customer projects (Vercel Knowledge Base, “Vercel April 2026 security incident”; Help Net Security, April 20, 2026). Variables marked Sensitive stayed encrypted and out of reach. Regular ones didn’t (GitGuardian, “Vercel April 2026 Incident”).
The breach made the Sensitive flag the one control that actually held. Build logs were a gap in that story: a Sensitive variable that got echoed into a build’s console output defeated its own protection, no OAuth compromise required. Closing that gap is a reasonable next step, and a narrow one. It only helps the fraction of variables a team bothered to flag.
The catch developers are pointing out
That fraction is the complaint showing up in developer response to the April breach. Vercel’s own incident guidance tells customers to audit every environment variable not marked Sensitive and rotate anything that looks like a secret (GitGuardian). That advice only makes sense because marking a variable Sensitive is opt-in, not the default. A team that never flagged its API keys and database URLs gets nothing from either the April incident’s containment or July’s build-log fix. The Hacker News discussion of the breach kept circling the same point: the protection exists, but most projects’ secrets were never inside it.
Key Takeaways
- Vercel now replaces Sensitive environment variable values of 32+ characters with
[REDACTED]in build logs, shipped July 9, 2026. - Two system variables are always redacted regardless of length; everything else needs the Sensitive flag set to qualify.
- The fix follows an April 2026 breach in which attackers, via a compromised third-party AI tool’s OAuth access, decrypted non-Sensitive environment variables while Sensitive ones stayed protected.
- Runtime logs,
NEXT_PUBLIC_bundles and committed secrets are still outside this redaction’s scope — and outside the Sensitive flag’s protection entirely if a variable was never marked as such.
What to do
Mark every credential-bearing environment variable Sensitive, not just the ones that feel high-risk. That flag, not this week’s build-log fix, is what actually keeps a value encrypted and out of both a breach and a stray log line. If your project went through the April incident, this doesn’t retroactively protect what already leaked; keep working through Vercel’s rotation guidance for anything that wasn’t Sensitive at the time.


