CVE-2026-48501 is a high severity flaw (CVSS 7.4) in GitHub CLI. Before version 2.93.0, the gh attestation and gh release verify commands sent the user's authentication token to TUF repository mirror hosts. GitHub says to upgrade to 2.93.0, revoke the tokens that were used, and review audit logs.
What's affected
GitHub CLI (gh) version 2.92.0 and earlier. The patched version is 2.93.0.
The advisory names three commands: gh attestation, gh release verify and gh release verify-asset. Users who ran them with a github.com login sent that token to tuf-repo.github.com. Users with GH_ENTERPRISE_TOKEN or GITHUB_ENTERPRISE_TOKEN set sent the enterprise token to tuf-repo-cdn.sigstore.dev and tmaproduction.blob.core.windows.net, which GitHub says are not hosts it operates.
How to check if you're exposed
Check the installed version on laptops, build agents and CI images.
gh --version
Then search shell history and CI logs for runs of the three commands, since only people and jobs that ran them sent a token. Also list where tokens are set, such as GH_TOKEN, GH_ENTERPRISE_TOKEN and stored gh logins in CI secrets.
What to do now
- Upgrade gh to 2.93.0 or later on workstations, runners and base images.
- Revoke the authentication tokens used with GitHub CLI, including personal access tokens and the GitHub CLI OAuth app token, then create new ones.
- Review your personal security log and any relevant audit logs for unexpected actions by your account or enterprise.
- Prefer short lived, narrowly scoped tokens in CI so that a leak has less value.
Why it matters
The weakness is CWE-863, incorrect authorization. The advisory explains the cause: the CLI uses a shared HTTP client that attaches tokens automatically, and its host detection was loose. It treated any subdomain of github.com as github.com, so a GitHub Pages site received the user's token. For hosts it did not recognize at all, it fell back to the enterprise token.
GitHub states it has no evidence the tokens were logged, kept or used by anyone unauthorized. Even so, a token sent to a third party host is exposed, and rotation is the safe response. The record does not mark this CVE as exploited in the wild, and it is not on the CISA Known Exploited Vulnerabilities list.
The broader point is that tools which attach credentials to every outgoing request need a strict list of hosts that may receive them.
Paste your lockfile or manifest into the free in-browser dependency scan to see whether the GitHub CLI module is in your tree, including as a transitive dependency. Reachability analysis can then show whether your code calls the affected path, which helps you order the work.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to rotate tokens if I never ran the verify commands?
The advisory ties the leak to those commands. If neither you nor any job ran them, your token was not sent by this path, but upgrading is still sensible.
Sources
Last reviewed: 19 October 2026.
