Vercel Security Incident: Which Env Vars to Rotate
What Vercel told customers to do about environment variables, which credentials in an app backend that covers, and the order that keeps the app running.
Founder, Newly
Published Last updated
If a project on Vercel keeps API keys, tokens or database passwords in environment variables that were not marked sensitive, Vercel's own bulletin tells you to review and rotate them. Create the new credential first, save it in Vercel, redeploy, then revoke the old one. Vercel closed the incident on October 16, 2026.
What did Vercel say happened, and what does it ask customers to do?
The facts below come from Vercel's April 2026 security incident bulletin, read on October 24, 2026. It is Vercel's own account and has been updated several times since April.
| Question | What the bulletin says |
|---|---|
| How it started | A third-party AI tool used by a Vercel employee was breached. That let an attacker take over the employee's Vercel Google Workspace account and reach systems from there. |
| What was reachable | Environment variables that were not marked sensitive could be enumerated and decrypted. Vercel says a limited subset of customers was affected. |
| What it asks you to do | Review and rotate variables not marked sensitive. Use the sensitive variables feature. Set Deployment Protection to Standard at a minimum and rotate protection tokens. Review activity logs and recent deployments. Use an authenticator app or a passkey. |
| Status | Closed. The bulletin states that all remediation actions were complete on October 16, 2026. |
From outside, you cannot tell whether your project was in the affected subset. The practical step is the one Vercel lists, and for most small backends it takes an afternoon.
Why does the bulletin say "sensitive" when the dashboard says Secret?
Vercel's environment variable docs, last updated August 28, 2026, now offer two types. Config values stay readable to members with access. Secret values are write-only after saving. Existing sensitive variables are treated as Secrets. So when the bulletin says "not marked sensitive", read it as every variable showing a Config label.
Does this apply to an app built with Newly or another AI builder?
Only through whatever you run on Vercel. Newly builds a real iPhone and Android app with React Native and Expo, and you can download the code or connect your own repository. If you then put a web version, an API route, a webhook receiver or a landing page on Vercel, that project's variables are in scope. The app on the phone is not hosted there.
Variables prefixed with EXPO_PUBLIC_ are a separate matter. Expo's documentation says they are inlined into the app bundle and visible in plain text in the compiled application, and that anything included in client-side code should be treated as public. Nothing about this incident changes that. If a secret key ever sat in one of them, rotate it for that reason, which OWASP lists as M1 in its Mobile Top 10. Our 15-minute check covers that part.
Which credentials should I rotate, and how?
Open each project, then the team settings, and read the Environment Variables page. Every variable holding a credential and labelled Config goes on the list. This table covers what app backends usually hold. For a wider runbook, see Red's guide to rotating secrets after a breach.
| Variable holds | Rotate for this incident? | What to know first |
|---|---|---|
| AI provider API key | Yes, if stored as Config | Create a new key at the provider, then read its usage page for spend you did not cause. |
| Stripe secret or restricted key | Yes, if stored as Config | Stripe's key rotation lets you set the old key to expire now or keep both working for up to 7 days. Choose now if you suspect misuse. Webhook signing secrets are separate and also need replacing. |
| Supabase secret key (service role) | Yes, if stored as Config | It bypasses Row Level Security, so treat it as the most valuable key you hold. |
| Database password or connection string | Yes | Resetting it ends every open connection. Pick a quiet hour. |
| JWT secret | Only if it was stored as Config | Changing it signs every user out. Supabase's signing keys avoid that; the same Vercel guide has the steps. |
| Deployment Protection bypass secret | Yes, if you use one | Regenerating it invalidates previous deployments, so redeploy. Webhook URLs that carry it as a query parameter need the new value too. |
| Supabase publishable (anon) key, Stripe publishable key | No | Both are public by design. Check Row Level Security instead. |
What a rotation cannot undo
A new key stops future use of the old one. It does not tell you whether the old one was already used, and it does not repair data someone read or changed. That question is answered by the provider's logs, covered below.
In what order do I rotate without breaking the live app?
Vercel's rotation guide says the key is updating Vercel before you invalidate the old credential. Two details catch people out.
- A change to a variable applies only to new deployments. Old deployment URLs keep working with the old value until you revoke it, then they fail.
- A team-level variable can feed several projects. Check the Link to Projects field and redeploy each one before you revoke anything.
OWASP's secrets management cheat sheet says exposed keys should be revoked immediately. That is the case to choose when you have a reason to think the key was read. Without one, the overlap in the diagram avoids an outage. While you are in the dashboard, also set Deployment Protection per Vercel's documentation: Standard Protection covers every deployment except production domains, and All Deployments covers production too. Expect the generated production URL to become restricted under Standard.
How do I check whether a key was used by someone else?
Check at the provider, because that is where the use would be recorded. Stripe shows request logs per key. Most AI providers have a usage page, and your database keeps its own logs; open each and see what it offers. Look at the period from April 2026 to the day you rotated, and note any unfamiliar address, region, model or endpoint.
On the Vercel side, the Activity Log lists events on a team, and Vercel's bulletin asks you to review it along with recent deployments. A deployment or setting change you did not make belongs in a report to Vercel support.
Keep the three states honest. Unrecognised traffic is detected. Nothing odd in a log is unknown, because a log shows only what was recorded. It becomes confirmed by owner evidence when you hold the provider's key list with the old key gone and logs for the period.
Credentials also leak through paths Vercel never touched. Red's note on bots requesting .env and .git is a 30-second check for your own domain.
Where do you stand?
Everything starts as unknown. Move an item to confirmed only when you hold the evidence listed under it.
Your rotation check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
The hub at newly.app/security lists the other checks in this series.
Frequently asked questions
I marked my variables as sensitive. Do I still need to rotate?
Vercel's bulletin asks customers to review and rotate the variables that were not marked sensitive. A key that was only ever stored as sensitive is outside that instruction. The catch is copies: if the same key also sat as an unmarked variable in another project, at team level, or in a Preview or Development target, rotate it. Vercel's docs now call the two types Config and Secret, and existing sensitive variables are treated as Secrets.
My Expo app does not use Vercel. Does any of this apply?
Only if something around the app runs there, such as a web version, an API route, a webhook receiver or a landing page. If nothing does, there is nothing to rotate for this incident. Other hosts publish their own bulletins, and the same rotation order applies when one of them tells you to rotate.
Will rotating keys break my live app?
It can, if you revoke the old credential before the new one is deployed. Create the new credential, save it in Vercel, redeploy, confirm the app works, then revoke the old one. Two resets cost more: changing a Supabase JWT secret signs every user out unless you migrate to signing keys, and resetting a database password ends every open connection.
How do I know whether someone used a key that was exposed?
Vercel cannot tell you; the provider that issued the key can. Read the provider's usage or request logs for the period since April 2026 and look for traffic you do not recognise: unfamiliar IP addresses, regions, models or endpoints. No unfamiliar traffic is unknown, not confirmed, because a log only shows what the provider recorded.
Do I need to rotate the Supabase publishable key (anon key)?
For this incident, no. Supabase documents the publishable key as readable by anyone, limited by Row Level Security. Rotate the secret key (service role), the JWT secret if you think it was stored as an unmarked variable, and the database password. Then check your Row Level Security policies, because the publishable key is only as limited as those rules.
Can a scan tell me whether my Vercel variables leaked?
No. The free scan on red.run.cloud works from outside. It can find keys shipped in your site's bundles and readable .env or .git paths on a domain you own. It cannot see the values in your Vercel dashboard or whether you rotated them, so those stay unknown until you hold the evidence yourself.
Sources
All sources were opened on October 24, 2026.
- Vercel April 2026 security incident, Vercel Knowledge Base
- Config and Secret environment variables, Vercel docs
- Rotating environment variables, Vercel docs
- Environment variables, Vercel docs
- Deployment Protection, Vercel docs
- Protection Bypass for Automation, Vercel docs
- Using the Activity Log, Vercel docs
- Rotating secrets for the Supabase integration, Vercel Knowledge Base
- API keys: publishable and secret, Supabase docs
- API keys, Stripe docs
- Environment variables in Expo, Expo docs
- Environment variables on EAS, Expo docs
- M1: Improper Credential Usage, OWASP Mobile Top 10
- Secrets Management Cheat Sheet, OWASP Cheat Sheet Series