CVE-2026-48501: GitHub CLI tokens leak via `gh attestation` commands

Published May 29, 2026
·
Updated

Summary

GitHub CLI incorrectly includes an authorization header in API requests to TUF repository mirrors via gh attestation, gh release verify, and gh release verify-asset commands.

Affected users:

- Authenticated github.com users who previously ran gh attestation commands, gh release verify, or gh release verify-asset: the github.com token was included in requests to tuf-repo.github.com, a GitHub Pages domain that is not a GitHub API endpoint. All authentication types are affected. - Users with GHENTERPRISETOKEN or GITHUBENTERPRISETOKEN set who previously ran gh attestation commands, gh release verify, or gh release verify-asset: the enterprise token was included in requests to external hosts tuf-repo-cdn.sigstore.dev and tmaproduction.blob.core.windows.net. These hosts are not operated by GitHub.

Details

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 GHENTERPRISETOKEN 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.

Impact

Tokens were transmitted in HTTP headers to the listed hosts during normal gh attestation, gh release verify, and gh release verify-asset operations. There is no evidence that tokens were logged, retained, or accessed by unauthorized parties. If a token were captured, it would grant the same access as the token holder, potentially including private repositories, organization resources, or enterprise administration depending on token type and permissions.

Remediation and mitigation

1. Revoke authentication tokens used with the GitHub CLI: - Personal access tokens - GitHub CLI OAuth app 2. Upgrade gh to 2.93.0. 3. Review personal security logs and any relevant audit logs for actions associated with personal or enterprise accounts.

Other sources

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 GHENTERPRISETOKEN 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.

MITRE

Affected Software

2 affected componentsFixes available
go/github.com/cli/cli/v2<=2.92.0
2.93.0
GitHub CLI<2.93.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/github.com/cli/cli/v2 to a version that resolves this vulnerability.

    Fixed in 2.93.0
  2. Upgrade

    Upgrade github/cli/gh to a version that resolves this vulnerability.

    Fixed in 2.93.0
  3. Operational

    Review your security logs and relevant audit logs for actions associated with personal or enterprise accounts, and revoke authentication tokens used with the GitHub CLI if necessary (affected commands: `gh attestation`, `gh release verify`, `gh release verify-asset`).

Event History

May 29, 2026
CVE Published
via MITRE·03:14 PM
Data Sourced
via MITRE·03:14 PM
DescriptionSeverityWeakness
Advisory Published
via GitHub·03:30 PM
Data Sourced
via GitHub·03:30 PM
DescriptionSeverityWeaknessAffected Software
Data Sourced
via NVD·04:16 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-48501?

The severity of CVE-2026-48501 is high, with a score of 7.4.

2

Who is affected by CVE-2026-48501?

Authenticated GitHub users who previously executed `gh attestation` commands are affected by CVE-2026-48501.

3

How can I fix CVE-2026-48501?

To fix CVE-2026-48501, update the GitHub CLI to the latest version that addresses this vulnerability.

4

What commands are related to CVE-2026-48501?

The commands related to CVE-2026-48501 include `gh attestation`, `gh release verify`, and `gh release verify-asset`.

5

What impact does CVE-2026-48501 have on users?

CVE-2026-48501 can lead to unauthorized exposure of an authorization header in API requests to TUF repository mirrors.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203