CVE-2026-48501: GitHub CLI tokens leak via `gh attestation` commands
GitHub CLI (gh) is GitHub’s official command line tool. Prior to 2.93.0, GitHub CLI incorrectly includes authorization header in API requests to TUF repository mirrors via gh attestation, gh release verify, and gh release verify-asset commands. The CLI uses a shared HTTP client with an authentication layer that automatically attaches tokens to outgoing requests. This layer lacks accurate host detection and can incorrectly attribute the target host, providing it with a token it should never receive. Specifically, the host normalization logic collapses any *.github.com subdomain to github.com, so a request to tuf-repo.github.com (a GitHub Pages site, not a GitHub API endpoint) is treated as a request to github.com and receives the user's github.com token. For hosts that don't match github.com or a known GHES instance at all, the resolver falls back to GH_ENTERPRISE_TOKEN if set. The gh attestation, gh release verify and gh release verify-asset commands fetch data from several external hosts as part of their normal operation (TUF metadata from tuf-repo.github.com and tuf-repo-cdn.sigstore.dev, artifact bundles from Azure Blob Storage). Because these requests go through the same authenticated HTTP client, the token is sent to all of them. This vulnerability is fixed in 2.93.0.
HarborGuard Analysis
HarborGuard analysisSynopsis
GitHub CLI (gh) leaks authentication tokens through `gh attestation`, `gh release verify`, and `gh release verify-asset` commands due to a host-normalization flaw in its shared HTTP client. Because any `*.github.com` subdomain is collapsed to `github.com`, requests to `tuf-repo.github.com` (a GitHub Pages site) and other external hosts receive the user's github.com token, and unmatched hosts can receive `GH_ENTERPRISE_TOKEN`. An attacker positioned to observe or control responses from these endpoints can capture user tokens and reuse them to read and modify repositories and other resources the token authorizes. The description notes this is fixed in gh 2.93.0; a patched-image rebuild at that version is available on HarborGuard for affected environments once the upstream release is ingested.
HarborGuard Coverage
Detection is available across every HarborGuard environment: CVE-2026-48501 is ingested from upstream advisory feeds within minutes of publication and matched against `cli/cli` versions in customer registries, build pipelines, and custom-built images that bundle `gh`.
AvailableTriage is available with the published CVSS 3.1 score of 7.4 (High) weighted by each customer's compliance policy, so environments that treat token-disclosure issues as critical see it escalated accordingly. Findings are routed to the security inbox configured for the owning team inside each customer org.
AvailableA patched-image rebuild at gh 2.93.0 becomes available on HarborGuard for environments running an affected version. For customers who opt into auto-remediation, the rebuild is produced, the regression suite is run against it, and a PR is opened against the workloads that reference the affected image.
Pending upstreamExploit Conditions
- Network reachabilityRequired
The attacker must be able to influence responses from one of the external hosts the gh client contacts over the network (for example tuf-repo.github.com, tuf-repo-cdn.sigstore.dev, or Azure Blob Storage), so over-the-network positioning is required.
- AuthenticationNot required
PR:N: the attacker does not need any GitHub credentials of their own; the victim's gh client volunteers the token.
- Victim interactionNot required
UI:N: no user click or social-engineering step is needed beyond the victim running a normal `gh attestation` or `gh release verify` command.
- Attack complexityDetail
AC:H: exploitation depends on the attacker being able to observe or man-in-the-middle traffic to the specific third-party hosts gh contacts, or to control one of those endpoints, which is not trivially reliable.
Blast Radius
- Discloses the user's github.com OAuth or PAT token to third-party hosts including a GitHub Pages site, a Sigstore CDN, and Azure Blob Storage, where it can be captured by anyone with access to those request logs or response paths.
- If `GH_ENTERPRISE_TOKEN` is set, leaks the GitHub Enterprise Server token to arbitrary unmatched hosts contacted during attestation or release verification.
- Captured tokens let an attacker read and modify repositories, releases, and other resources to the full extent of the victim's GitHub permissions, including pushing code or altering release artifacts.
How HarborGuard Handles This
Available on HarborGuard: once gh 2.93.0 is ingested from upstream feeds, a patched-image rebuild at that version is offered for any image containing an affected `gh` binary. For customers with auto-remediation enabled, the rebuild is produced, the regression suite runs against it, and a PR is opened against affected workloads; median time from CVE publication to merged patch PR for high-severity issues is around 90 minutes in those environments. Until the rebuild is rolled out, suggested compensating controls include avoiding `gh attestation`, `gh release verify`, and `gh release verify-asset` in CI contexts that hold long-lived tokens, scoping `GH_ENTERPRISE_TOKEN` narrowly, and rotating any github.com or enterprise tokens that have been used with affected gh versions.
Metrics
- CVSS v3.1
- 7.4
- Severity
- HIGH
- Fixed in
- —
- Affected Products
- 1
- cli / cli< 2.93.0
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N