Cloud · Secret guide

Leaked Vercel API Token: what to do in the first hour

High severityDetected onlyLast verified · 5 min read

A Vercel API token lets whoever holds it call the Vercel REST API as you, with the same reach as your account or team scope. That means listing projects, reading and changing environment variables, creating deployments, editing domains and removing resources. The token does not open your laptop or your Git provider, but the environment variables of your projects often hold the keys to everything else. Delete the token first, then work out what it could reach.

Check your GitHub account for leaked secrets — free

Provider
Vercel
Severity
High
Impact
Cloud infrastructure access
Checked live by LeakWatch
No

What a Vercel API token looks like

A Vercel token is a plain string of 24 letters and digits. It has no prefix, no dash and no readable marker:

…XXXX   Vercel API token (masked, 24 letters and digits, no prefix)

Nothing in the string says it belongs to Vercel, so the context does the identification: a variable such as VERCEL_TOKEN, a --token argument to the vercel command line, or a call to api.vercel.com. A bare 24-character string found alone cannot be attributed with confidence. Do not confuse it with the OIDC tokens Vercel issues to builds (those are JWTs and expire quickly) or with deploy hooks, which are URLs rather than tokens.

How Vercel API tokens get leaked

  • CI configuration. A --token value typed into a GitHub Actions workflow, a package.json script or a Makefile instead of being read from a secret.
  • Environment files. A .env file with VERCEL_TOKEN committed next to the application, or a .vercel folder copied into the repository.
  • Shell history and logs. A command such as vercel --token … echoed in a CI log, a terminal screenshot or a bug report.
  • Shared scripts. Deployment helpers, release bots and chat-ops tools that carry the token in plain text.
  • Copy-pasted tutorials. A token pasted into an issue or a gist while asking why a deployment fails.

What to do in the first hour

  1. Find the token in your account. Open your account settings in the Vercel dashboard and go to the tokens page. The list shows each token’s name, its scope and when it was last used. Match the name and the last use against what leaked.
  2. Create a replacement with a clear name and, if you can, an expiration date and a narrow team scope. Store it in your CI secret store, not in the repository.
  3. Deploy the new token where the old one was used and check that a deployment still goes through.
  4. Delete the exposed token from the same list. A deleted token is rejected on new API calls.
  5. Audit what it could do. Check the activity log of the account and of each team the token could reach. Look for deployments you did not trigger, new or changed domains, new integrations, changed environment variables and added team members.
  6. Rotate the secrets behind your projects. Anyone who could read environment variables could read database URLs and third-party keys. Treat each of them as exposed if the token had access to the project, and rotate them at their own provider.
  7. Check what else was in the same file. A repository that held this token often holds other keys. See I accidentally pushed an API key to GitHub.

Not sure what else leaked from the same repository? Run a free scan.

Not sure what else leaked? Run a free scan.

Revoke it at Vercel

Vercel tokens are managed from the tokens section of your account settings, after you sign in with the account that created them. Find the exposed token in the list and delete it. Tokens belong to the user who created them, so a token you cannot find may sit in another person’s account or in a service account; ask the team owner to check the team’s member list. Vercel’s documentation covers token creation and scopes. The dashboard changes from time to time, so if the wording differs from this guide, look for the section of your account settings where tokens are created and listed.

How LeakWatch detects it

The rule is called Vercel API Token. Because the token has no prefix, the rule does not match a bare string: it requires the word vercel within about forty characters before a 24-character alphanumeric value. A token pasted without any Vercel wording around it will be missed, and an unrelated 24-character string near the word may be reported. The severity is high. This type is not checked live: LeakWatch does not call Vercel with the value, so a finding means a matching string was seen, not that the token still works. Check in your token list whether it is still active.

LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.

FAQ

Can someone deploy to my production site with this token?

Potentially yes, if the token’s scope includes the project. A Vercel token acts with the permissions of the account or team scope it was created for, so it can trigger deployments and change settings. Check your deployment history for builds you did not start.

I found a 24-character string near the word "vercel". Is it a token?

Not necessarily. It could be a project or team identifier, a hash or a sample value. Compare its last characters with the tokens in your account, or look at how the code uses it.

The token was only in a private repository. Should I still delete it?

Yes, if the repository has collaborators, forks or CI logs, or if you are unsure who can read it. Creating a new token takes a minute, and a token you doubt is worth less than a fresh one.

Get alerted next time a secret leaks — create a free account

LeakWatch is not affiliated with Vercel.