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 CI/CD pipelines for supply chain security, this means the very commands designed to verify artifact integrity have been leaking the credentials that protect those artifacts.

CVE-2026-48501 carries a CVSS 3.1 score of 7.4 (High) and affects all GitHub CLI versions prior to v2.93.0. The vulnerability is classified under CWE-863 (Incorrect Authorization), a weakness that appears on the CWE Top 25 Most Dangerous Software Weaknesses list. This is notably the second token leakage vulnerability in GitHub CLI within roughly eighteen months, following CVE-2024-53858 in November 2024, both 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 a common authenticated client. This client includes an authentication resolver layer that decides which token to attach to each outgoing request based on the destination host. The resolver contains two distinct logic flaws that together cause tokens to leak to three external hosts.

Flaw 1: Wildcard Subdomain Collapsing

The host normalization logic collapses any *.github.com subdomain to github.com. This means a request to tuf-repo.github.com, which is a GitHub Pages site and not a GitHub API endpoint, is treated as a request to github.com itself. The user's github.com OAuth or personal access token is then attached to the outgoing request via the Authorization header.

This is a significant distinction: GitHub Pages sites are user controlled content hosting domains. They are not part of the GitHub API surface. Treating them as equivalent to github.com for authentication purposes 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. This causes the enterprise token to be sent to fully external hosts like 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. Because all of these requests flow through the same authenticated HTTP client, the token is included in the Authorization header for every one of them.

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, yielding a score of 7.4:

The High attack complexity rating reflects that exploitation requires the attacker to be positioned to intercept the token: either by 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 operated a service that logged incoming request headers, the token would be directly captured from server side logs. While these are operated by trusted organizations (GitHub, Sigstore, Microsoft), 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 controlled server, receiving the authentication token in the process.

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

Patch Information

GitHub addressed 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, making v2.93.0 the first patched release.

The v2.93.0 patch corrects the vulnerability by tightening the host detection logic in the shared HTTP client's authentication resolver layer. The specific changes address both failure modes:

1. Subdomain collapsing is eliminated for non-API hosts. Subdomains of github.com that are not actual API endpoints (such as tuf-repo.github.com) are now correctly recognized as external and do not receive the user's github.com token.

2. Enterprise token fallback no longer fires for third party infrastructure hosts. The resolver no longer sends GH_ENTERPRISE_TOKEN to hosts like tuf-repo-cdn.sigstore.dev and tmaproduction.blob.core.windows.net that are clearly not GHES instances.

As a result, tokens are only included in requests that are 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 remediation developer credited in the advisory is @babakks, with @BagToad and @kommendorkapten credited as remediation reviewers.

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

Post-patch actions:

Users who have previously run any of the affected commands on versions prior to 2.93.0 should rotate their GitHub authentication tokens as a precautionary measure. While the advisory notes "no evidence that tokens were logged, retained, or accessed by unauthorized parties," rotating tokens eliminates residual risk from potential undetected interception. 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 completed. Temporarily unsetting enterprise token environment variables also prevents the fallback leakage 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. This includes every release from the initial introduction of the gh attestation, gh release verify, and gh release verify-asset commands through v2.92.0.

Specifically:

• 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 only triggered 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 specific issue.

Users with GH_ENTERPRISE_TOKEN or GITHUB_ENTERPRISE_TOKEN environment variables set face amplified exposure, as these enterprise tokens are sent to the fully external hosts tuf-repo-cdn.sigstore.dev and tmaproduction.blob.core.windows.net via the fallback mechanism.

Version tracking data indicates that v2.92.0 (the last vulnerable version) accumulated 15,076 downloads in approximately four weeks prior to the patch release, providing 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 these involve token leakage from the same class of host resolution flaw in the HTTP client authentication layer:

The earlier token leakage vulnerability (CVE-2024-53858) involved gh repo clone, gh repo fork, and gh pr checkout commands leaking 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.

The recurrence of token leakage vulnerabilities across two separate host resolution logic flaws, roughly eighteen months apart, suggests an architectural weakness in the CLI's HTTP client authentication layer that warrants deeper structural review beyond 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 maintains a structured security reporting process through private vulnerability reporting at 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