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.

The remote Fedora 44 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2026-4e77362489 advisory.

    Update to 2.97.0


Tenable has extracted the preceding description block directly from the Fedora security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-48501)

Note that Nessus relies on the presence of the package as reported by the vendor.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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. (CVE-2026-48501)

ID	Name	Product	Family	Type	Severity
331603	Fedora 44 : gh (2026-4e77362489)	Nessus	Fedora Local Security Checks	Local	critical
318545	Linux Distros Unpatched Vulnerability : CVE-2026-48501	Nessus	Misc.	Local	critical
442491	SCA: security update for github.com/cli/cli/v2 (GHSA-8xvp-7hj6-mcj9)	Tenable Cloud Security	SCA Checks	Local	critical
442491	SCA: security update for github.com/cli/cli/v2 (GHSA-8xvp-7hj6-mcj9)	Tenable Self-Hosted Container Security	SCA Checks	Local	critical

Detections

Analytics

CVE-2026-48501

critical

Tenable Plugins

critical

critical

critical

critical