Leaked secretsBy Dynv team3 min read

I leaked a GitHub token: what to do, step by step

Short answer: delete the token in GitHub (Settings, Developer settings, Personal access tokens), create a replacement with the narrowest scope that works, and update whatever used it. GitHub's own remediation guide says the most important step is revoking the secret with its provider; removing it from your repository, pushing a new commit, or deleting and recreating the repository "do not prevent the secret from being exploited."

This is the GitHub-specific page for the leaked-key playbook, written from GitHub’s docs: managing your personal access tokens, remediating a leaked secret and about secret scanning.

Delete the token

From GitHub’s documentation for a personal access token:

  1. In the upper-right corner of any GitHub page, click your profile picture, then Settings.
  2. In the left sidebar, click Developer settings.
  3. Under Personal access tokens, click Fine-grained tokens or Tokens (classic), depending on the kind you’re deleting.
  4. Click Delete next to the token.

One consequence GitHub notes: “If you delete a personal access token that was used to create a deploy key, the deploy key will also be deleted.” Check for deploy keys before you delete if something depends on them. The docs also mention that if you find a leaked token belonging to someone else, you can submit a revocation request through GitHub’s REST API.

Follow GitHub’s remediation steps

GitHub’s guide for a leaked secret in a repository walks through four steps. In short:

  1. Identify the secret and gather context: its type and provider, where it was committed (git log -S helps find who), and who owns it.
  2. Assess the risk: is it still active, is the repository public, is it a production credential, does the alert show a public exposure or multiple leaks label? Which services depend on it?
  3. Strategize: for a high-risk secret (still active, public, or production) revoke immediately. If downtime is a concern, GitHub says you may “first generate a new secret with the same permissions, make the application start using the new token, and then revoke the old secret.”
  4. Revoke the secret, then generate a replacement if needed.

GitHub’s secret scanning docs add two relevant points: “While you can also remove secrets from your Git history, this is time-intensive and often unnecessary if you’ve already revoked the credential,” and for partner secrets, GitHub notifies the provider “so they can take action, such as revoking the credential.” That is for secrets of other providers found in your repository; for a GitHub token you still delete it yourself.

Make the replacement smaller

  • Prefer fine-grained tokens scoped to specific repositories and permissions where they work.
  • Give automation its own token or app rather than reusing a personal token.
  • Set an expiration date if the option is offered.
  • For CI, avoid long-lived tokens where the platform supports short-lived credentials (patterns).
  • Turn on secret scanning (and push protection, if your plan has it) for the repository so the next one is flagged or blocked (GitHub’s docs say secret scanning is free for public repositories and, for private repositories, part of a paid security offering; check what your plan includes).

After the provider is fixed: every other copy

Replacing the key at GitHub is half the job. The same value is usually also in other services, a CI variable, a teammate’s .env or another vault. With Dynv you can preview one operation that finds each copy it knows about (including the same value under another name) and replaces them together: pipe the new value in so it never lands in shell history, for example pbpaste | dynv rotate GITHUB_TOKEN --leaked --stdin --dry-run, then run it again with --yes (the plan also suggests copies under other names, which you add with --also SERVICE:KEY). --leaked means “everywhere, no fallback, no stages; the old value stops working now”, which is what you want after a leak. Dynv only knows copies stored in Dynv; search repositories, CI and chat for the old value’s prefix yourself. The generic order of operations, with the evidence on how fast leaked keys are used, is in the 15-minute playbook.

Limits of this page

  • We read GitHub’s own documentation on 2026-11-01 (linked above) and did not exercise GitHub’s console or API for this post. Console layouts and defaults change; follow GitHub’s current instructions where they differ.
  • If the key was in a repository, rotating it is the fix; cleaning Git history is housekeeping (how).
  • If an AI chat or an agent saw the key, see what to do.

Facts last verified . Spotted an error? Tell us.

New here? Start here for the guides in a sensible order.