Rotate, Redeploy, Revoke: Our Response to the Vercel Breach

On April 19, 2026, Vercel disclosed a security incident traced to a compromised third-party OAuth application inside their Google Workspace. We ran the response across every webvise-managed Vercel project before the weekend was out, and audit logs on both Vercel and the Google Workspaces we administer came back clean. This wasn't a vulnerability in Vercel's own code. It was a SaaS-to-SaaS supply-chain compromise through an OAuth trust boundary, and the shape of it changes what a proper response looks like.

Rotating secrets in your Vercel dashboard is maybe half the response. The other half lives in Google Workspace, and most writeups are not covering it.

You read the disclosure and cycled every key you could find. That is the right first move. This article walks through what we actually ran end-to-end, the technical gotcha that makes rotation apply to running functions, and why the shape of this breach changes how your response plan should look next time.

• Rotating Vercel env vars changes the dashboard, not the running functions. Values only take effect on the next deploy.

• The Google Workspace OAuth audit is the half that barely gets discussed. That is the trust path the attacker used to reach Vercel.

• This wasn't a Vercel vulnerability. It was a SaaS-to-SaaS compromise through an OAuth grant, and a normal CVE-style response doesn't close the loop.

• Long-term, move secrets out of env vars and into a runtime secret manager. Require phishing-resistant MFA on anyone who can install OAuth apps.

• Monthly audits of third-party OAuth grants in your identity provider are now part of the baseline, not a maturity upgrade.

What Vercel Actually Disclosed

The short version: a third-party SaaS application with OAuth access inside Vercel's Google Workspace was compromised, and the attacker used that trust boundary to reach environment variable values across a subset of customer projects. Vercel published an OAuth client ID as an indicator of compromise and asked every customer to rotate any secret stored as an environment variable. Nothing about this involved a vulnerability in Vercel's own code. The attack surface was the identity trust graph between two SaaS tools.

That matters for how you respond. If the vulnerability is in the platform's own code, you patch, rotate what leaked, and move on. If the vulnerability is in the trust path between platforms, rotation is necessary but it does not close the hole. You also have to revoke the grant the attacker rode in on, or the next compromise of that same tool repeats the same blast radius.

If you want a second pair of eyes on your Vercel setup before next weekend's post-mortem gets written about you, we run security reviews across Vercel teams, Google Workspaces, and SaaS-to-SaaS grants.

Step One: Rotate the Secrets That Actually Matter

We treated every environment variable that could grant access to anything as compromised by default. That is the assumption the disclosure requires. Here are the secret classes we reissued across managed projects.

• Database credentials. Connection strings, read-only replica passwords, and admin-tier role keys on every project with a database backend.

• Resend API keys for transactional email on every project that sends verification, notification, or signup messages.

• Google API credentials for Workspace, Calendar, Drive, and Analytics integrations that run server-side.

• AI Gateway keys including model access tokens, provider credentials, and rate-limit tokens for anything routed through the gateway.

• Ingest integration credentials for webhook endpoints, event pipelines, and anything pulling data into the project from outside.

Two categories worth double-checking: variables ending in `_URL` that embed credentials inside connection strings, and anything labeled `_TEST` or `_DEV` that turns out to point at production. Rotate those with the rest. An attacker reading env vars does not care which flag you picked or what the variable name suggests it does.

Step Two: Redeploy (The Technical Gotcha That Makes Rotation Real)

This is the part that matters most and gets the least airtime. Vercel applies environment variable changes at build and deploy time, not at runtime. A project you updated and left alone is still running the build you shipped yesterday, which still has the old secret baked into its runtime. You rotated the dashboard, not the system.

Concrete version: you rotate your Resend API key at 10:14 and open a new tab to check something else. A function tries to send a verification email at 10:17, calls Resend with the old key still baked into its deployed env, and Resend rejects the request. Your user does not get their email. Multiply that by every function, every cron, and every webhook handler running the old build.

To verify your response, open the Deployments tab on each project and find a deployment timestamped after your rotation. If the top row shows a timestamp earlier than when you rotated, the rotation didn't make it into any running process. The second explicit step in our response was a forced production redeploy on every managed project after rotation, before moving on.

Step Three: Revoke the Google Workspace OAuth Grant

This is the half of the response that barely got discussed in weekend threads. The incident originated in Google Workspace. The attacker got in via a third-party OAuth application with a granted scope inside Workspace, then pivoted into Vercel through a SaaS-to-SaaS trust path. If you only rotated on the Vercel side, the same OAuth app is still sitting there with the same scope, ready to be abused the next time it gets compromised.

The path in your admin console: admin.google.com, security, api controls, app access control, third party apps. Search for the OAuth client ID Vercel published as an indicator. Revoke it if it is there. Then do the harder thing: review every other OAuth grant in the list, confirm every scope was intentional, and revoke anything you do not have a living reason to keep.

We ran this audit on every Workspace we administer. The indicator was not present, and most grants had legitimate business purpose. A handful did not, and we revoked them. We've since moved to a monthly cadence: audit OAuth grants at the start of every month, revoke anything unused in 30 days.

Step Four: The Long-Term Moves

Rotation and revocation handled the immediate exposure. The longer moves are what stop the next incident from being a weekend scramble. We are pushing these across managed projects over the coming weeks, and they are what we recommend to any team running a SaaS-heavy stack.

• Pull secrets at runtime from a secret manager instead of baking them into env vars. Rotation becomes a push, not a redeploy.

• Short-lived credentials for databases and APIs wherever the provider supports them. Minutes of validity, not months.

• Scheduled rotation for the credentials that cannot be made short-lived. Calendar-driven, not incident-driven.

• Phishing-resistant MFA on every admin account that can install OAuth applications in your identity provider. Passkeys or hardware tokens, nothing SMS-based.

• Monthly OAuth grant audits in Workspace, Microsoft 365, or whatever identity provider you run. The attacker's path this time was an OAuth grant; the attacker's path next time will be too.

Most teams do not have a single owner for any of these. That is the quiet reason incidents keep ending with the same bullets in the post-mortem. Talk to us about how webvise builds these into the maintenance retainer on every managed project.

Why This Breach Is Different

The breach model most security programs are built for: an attacker finds a CVE in a server you run, exploits it, and dumps your data. Rotation, patching, and perimeter monitoring cover that model. The incident that showed up on April 19 is a different shape.

An attacker compromises one SaaS tool your team authorized, then rides the trust relationship between that tool and your other SaaS tools to reach data neither would have given a stranger. Your Vercel account didn't get popped, and your Google Workspace didn't either. A third tool someone connected months ago got popped, and the scopes you granted that tool propagated the compromise downstream.

The defensive model has to match the attack model. That means treating OAuth grants as production dependencies, auditing them on a schedule, and moving secrets out of environment variables where an attacker with that grant can read them. Our audit logs came back clean this weekend, but that is the payoff for this specific incident, not proof the response model is future-proof.

We run security reviews on Vercel teams, Google Workspaces, and SaaS-to-SaaS identity graphs as part of every managed engagement at webvise. If you want an external pair of eyes on your setup before the next disclosure lands on a weekend, start a conversation.