Quick Look: CVE-2026-48501 — GitHub CLI Token Leakage via Flawed Host Normalization in TUF Verification Commands

Introduction

A flawed host normalization routine in GitHub CLI has been silently sending users' authentication tokens to three external hosts every time they run attestation or release verification commands. For any organization that has integrated gh attestation verify or gh release verify into its CI/CD pipelines for supply chain security, the commands designed to verify artifact integrity have been leaking the credentials that protect those artifacts.

CVE-2026-48501 has a CVSS 3.1 score of 7.4 (High) and affects all GitHub CLI versions prior to v2.93.0. It is classified under CWE-863 (Incorrect Authorization), which appears on the CWE Top 25 Most Dangerous Software Weaknesses list. It is also the second token leakage vulnerability in GitHub CLI in roughly eighteen months. The first was CVE-2024-53858 in November 2024, and both are rooted in the same HTTP client authentication layer.

Technical Information

Root Cause: Shared HTTP Client with Broken Host Detection

GitHub CLI routes all outgoing HTTP requests through one shared authenticated client. An authentication resolver layer in that client decides which token to attach to each request based on the destination host. The resolver has two separate logic flaws, and together they leak tokens to three external hosts.

Flaw 1: Wildcard Subdomain Collapsing

The host normalization logic collapses any *.github.com subdomain to github.com. A request to tuf-repo.github.com, which is a GitHub Pages site rather than a GitHub API endpoint, is therefore treated as a request to github.com itself, and the user's github.com OAuth or personal access token is attached to it in the Authorization header.

GitHub Pages sites are user-controlled content hosting domains and sit outside the GitHub API surface. Treating them as equivalent to github.com for authentication violates the principle of least privilege.

Flaw 2: Enterprise Token Fallback for Unknown Hosts

When a target host does not match github.com or a known GitHub Enterprise Server (GHES) instance, the resolver falls back to the GH_ENTERPRISE_TOKEN or GITHUB_ENTERPRISE_TOKEN environment variable if either is set. As a result, the enterprise token is sent to fully external hosts such as tuf-repo-cdn.sigstore.dev (a Sigstore CDN) and tmaproduction.blob.core.windows.net (Azure Blob Storage).

Affected Commands and Data Flows

Three commands trigger the vulnerable code path during their normal verification workflows:

These commands fetch TUF (The Update Framework) metadata from tuf-repo.github.com and tuf-repo-cdn.sigstore.dev, and artifact bundles from Azure Blob Storage at tmaproduction.blob.core.windows.net. Every one of these requests goes through the same authenticated HTTP client, so every one of them carries the token in its Authorization header.

CVSS v3.1 Vector Breakdown

The full CVSS vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, for a score of 7.4.

The High attack complexity rating reflects that the attacker must be in a position to intercept the token. That means controlling one of the three external hosts, performing a man-in-the-middle attack on the network path, or compromising DNS resolution for the TUF repository domains.

Exploitation Scenarios

Scenario 1: Man-in-the-Middle Interception. An attacker positioned on the network path between the CLI client and any of the three external hosts could capture the Authorization header containing the token. This requires compromising a network infrastructure component such as a DNS resolver, proxy, or router.

Scenario 2: Compromised External Host. If any of the external hosts were compromised, or ran a service that logged incoming request headers, the token would be captured directly from server-side logs. These hosts are operated by trusted organizations (GitHub, Sigstore, Microsoft), but the security model should not depend on external hosts never logging Authorization headers.

Scenario 3: DNS Hijacking. An attacker who can manipulate DNS resolution for tuf-repo.github.com or tuf-repo-cdn.sigstore.dev could redirect the CLI's requests to a server they control and receive the authentication token.

In every scenario, a captured token grants the same access the token holder has. Depending on the token type and permissions, this could include access to private repositories, organization resources, or enterprise administration capabilities.

Patch Information

GitHub fixed CVE-2026-48501 in GitHub CLI v2.93.0, released on May 27, 2026 (commit f96972ce). The advisory (GHSA-8xvp-7hj6-mcj9) lists all versions up to and including v2.92.0 as affected, so v2.93.0 is the first patched release.

The v2.93.0 patch tightens the host detection logic in the shared HTTP client's authentication resolver layer and addresses both flaws:

1. Subdomains of github.com that are not actual API endpoints, such as tuf-repo.github.com, are now recognized as external and no longer receive the user's github.com token.

2. The resolver no longer sends GH_ENTERPRISE_TOKEN to third-party infrastructure hosts such as tuf-repo-cdn.sigstore.dev and tmaproduction.blob.core.windows.net, which are clearly not GHES instances.

With both changes, tokens are included only in requests genuinely destined for GitHub API endpoints.

The v2.93.0 release also bumped the github.com/theupdateframework/go-tuf/v2 dependency from 2.4.1 to 2.4.2, which may include additional hardening for TUF client operations. The advisory credits @babakks as the remediation developer, with @BagToad and @kommendorkapten as remediation reviewers.

The full changelog between the vulnerable and patched versions is in the v2.92.0 to v2.93.0 comparison.

Post-patch actions:

Users who have run any of the affected commands on versions prior to 2.93.0 should rotate their GitHub authentication tokens as a precaution. The advisory notes "no evidence that tokens were logged, retained, or accessed by unauthorized parties," but rotating tokens removes any residual risk from interception that may have gone undetected. Enterprise tokens (GH_ENTERPRISE_TOKEN and GITHUB_ENTERPRISE_TOKEN) should also be rotated if they were set during the affected period.

For users who cannot upgrade immediately, the recommended workaround is to avoid running gh attestation, gh release verify, and gh release verify-asset until the upgrade is done. Temporarily unsetting the enterprise token environment variables also stops the fallback leak to external hosts.

Organizations managing GitHub CLI deployments should inventory all systems with versions prior to 2.93.0, enforce the upgrade through package management policies, and review CI/CD pipelines that use gh attestation verify or gh release verify for artifact verification.

Affected Systems and Versions

All versions of GitHub CLI prior to v2.93.0 are affected. That covers every release from the introduction of the gh attestation, gh release verify, and gh release verify-asset commands through v2.92.0.

• Affected: GitHub CLI versions up to and including v2.92.0
• Fixed: GitHub CLI v2.93.0 (released May 27, 2026)
• Platforms: macOS, Windows, and Linux (all platforms where GitHub CLI is distributed)
• Environments: GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server 2.20+

The vulnerability is triggered only when a user runs one of the three affected commands (gh attestation, gh release verify, gh release verify-asset). Other gh commands are not affected by this issue.

Users who have the GH_ENTERPRISE_TOKEN or GITHUB_ENTERPRISE_TOKEN environment variable set face greater exposure, because the fallback mechanism sends those enterprise tokens to the fully external hosts tuf-repo-cdn.sigstore.dev and tmaproduction.blob.core.windows.net.

Version tracking data indicates that v2.92.0, the last vulnerable version, accumulated 15,076 downloads in approximately four weeks before the patch release. That gives a rough indicator of the active user base running vulnerable versions.

Vendor Security History

The cli/cli repository has published seven security advisories to date. Two of them involve token leakage from the same class of host resolution flaw in the HTTP client authentication layer:

In the earlier token leakage vulnerability (CVE-2024-53858), the gh repo clone, gh repo fork, and gh pr checkout commands leaked tokens to non-GitHub submodule hosts, because hosts other than github.com and ghe.com were incorrectly treated as GitHub Enterprise Server instances. That vulnerability was fixed in v2.63.0.

Two token leakage vulnerabilities from two separate host resolution flaws, roughly eighteen months apart, suggest an architectural weakness in the CLI's HTTP client authentication layer. That weakness warrants a deeper structural review than the individual point fixes applied in each advisory. The shared HTTP client pattern of "authenticate everything by default, then try to figure out which host deserves a token" inverts the safer approach of "authenticate nothing by default, then explicitly opt in for known API endpoints."

GitHub accepts security reports through private vulnerability reporting on the repository's security advisories page, and through HackerOne for bounty-eligible submissions.

References

• NVD Entry for CVE-2026-48501
• GitHub Advisory GHSA-8xvp-7hj6-mcj9
• GitHub CLI v2.93.0 Release
• Changelog: v2.92.0 to v2.93.0
• Cybersecurity Help: SB20260528250
• GitHub CLI Manual: gh attestation verify
• GitHub CLI Security Advisories
• Prior Token Leakage Advisory: GHSA-jwcm-9g39-pmcw (CVE-2024-53858)
• CWE-863: Incorrect Authorization
• GitHub CLI Repository
• Proofpoint: 2026 Vulnerability Exploitation in the Wild