CVE-2026-48501: GitHub CLI Authorization Token Leakage to External Services

Technical summary

GitHub CLI's authentication middleware automatically attaches bearer tokens to HTTP requests using a shared client without proper host validation. The host normalization logic collapses all *.github.com subdomains to 'github.com', causing requests intended for TUF mirrors (tuf-repo.github.com) to be treated as GitHub API calls and receive the user's GitHub token. For hosts outside the github.com namespace entirely, the client falls back to GH_ENTERPRISE_TOKEN if configured. The `gh attestation`, `gh release verify`, and `gh release verify-asset` commands make requests to multiple external endpoints (tuf-repo.github.com, tuf-repo-cdn.sigstore.dev, Azure Blob Storage) as part of their normal workflow, all routing through this misconfigured authentication layer. This results in credential leakage to services that should never receive authentication material. The root cause is inadequate host detection logic that fails to distinguish between GitHub-controlled endpoints and external third parties.

Business impact

Token compromise via this vulnerability creates a window for unauthorized repository access, potential code injection through release verification bypass, and account takeover. An attacker who intercepts the leaked token gains the same permissions as the compromised user account—able to read private repositories, push code, create or delete releases, and modify workflows. For organizations using GitHub CLI in CI/CD pipelines or automated release verification workflows, this becomes particularly severe, as service account tokens with elevated permissions could be stolen. The impact cascades when the compromised account has administrative or team lead privileges. Secondhand risk emerges from the verification commands themselves: if an attacker intercepts the verification process, they could potentially influence which releases or attestations are trusted.

Affected systems

GitHub CLI versions prior to 2.93.0 are affected. This includes all 2.92.x and earlier releases. Any system running an older version of `gh` is vulnerable if the user invokes `gh attestation`, `gh release verify`, or `gh release verify-asset` commands. The vulnerability affects Linux, macOS, and Windows platforms wherever GitHub CLI is installed. Organizations using GitHub CLI in automation, CI/CD systems, or local development workflows are at risk, particularly those leveraging release verification features for supply chain security.

Exploitability

Exploitation requires an attacker to be in a position to intercept network traffic (man-in-the-middle capability) or control one of the external services that receives the token (TUF mirrors, Sigstore CDN, or Azure endpoints). The CVSS score reflects this: the attack vector is network-based and requires high complexity (AC:H) due to the need to intercept or compromise a third-party service. However, once positioned to observe traffic, the exploit is straightforward—the token is automatically leaked with no additional user interaction required beyond running a standard release verification command. The vulnerability is not yet listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, though public disclosure increases the likelihood of exploitation.

Remediation

Immediately upgrade GitHub CLI to version 2.93.0 or later. This version fixes the host normalization logic and ensures tokens are only sent to legitimate GitHub endpoints. After upgrading, consider rotating any GitHub personal access tokens or organization tokens that may have been in use on affected systems, particularly if those systems operated on untrusted networks or if release verification commands were executed during a potential compromise window. Review CI/CD logs and git hosting audit trails for unexpected account activity during the vulnerability window.

Patch guidance

Update GitHub CLI to 2.93.0 or later. On macOS with Homebrew: `brew upgrade gh`. On Ubuntu/Debian: `sudo apt upgrade gh` or download the latest release from github.com/cli/cli/releases. On Windows with Winget: `winget upgrade GitHub.cli`. On other systems, consult the official installation guide at cli.github.com/manual/installation. Verify the update with `gh version`. Prioritize systems in CI/CD pipelines and those with service account tokens before general workstations.

Detection guidance

Check installed GitHub CLI version on developer machines and CI/CD runners using `gh version`. Audit HTTP request logs (if available) on systems running GitHub CLI during the vulnerability period for unexpected token transmission to external hosts. Monitor GitHub audit logs for suspicious token usage, including API calls from unusual IPs or times correlating with release verification operations. If using GitHub Enterprise, check audit logs for GH_ENTERPRISE_TOKEN usage to suspicious destinations. Network-level detection is challenging without packet inspection, but monitoring for TLS handshakes to tuf-repo.github.com, sigstore.dev CDN, or Azure endpoints from internal systems could indicate active exploitation.

Why prioritize this

This is a HIGH severity vulnerability (CVSS 7.4) involving direct credential leakage to untrusted third parties. Token compromise has downstream account takeover potential, making it a serious supply chain risk, particularly for teams relying on GitHub CLI for release verification and attestation workflows. The vulnerability affects a widely-used tool and requires no user action beyond normal command execution. While exploitation requires network positioning, the barrier is not prohibitively high in untrusted or compromised network environments. Immediate patching is warranted.

Risk score, explained

The CVSS 3.1 score of 7.4 (HIGH) reflects network attack vector (AV:N), high complexity due to required interception (AC:H), no privileges needed (PR:N), and no user interaction required (UI:N). Severity is scoped to the user's account and credentials (S:U). Confidentiality and integrity are both high impact (C:H, I:H) because the leaked token enables both reading private data and modifying repositories. Availability is not impacted (A:N). The score appropriately reflects a serious credential leakage issue that, while not trivial to exploit, has substantial consequences once successful.

Frequently asked questions