GitHub CLI token leak: gh attestation and gh release verify could send your token to TUF and artifact hosts

Who is affected

GitHub CLI (gh) is GitHub’s official command-line tool. The affected commands are three “verification” commands: gh attestation, gh release verify and gh release verify-asset. They check where a file or release was built and whether it has been changed.

A “token” is a string that stands in for your identity: a program holding it can access GitHub with your permissions. GH_ENTERPRISE_TOKEN / GITHUB_ENTERPRISE_TOKEN hold the token for GitHub Enterprise Server; GH_TOKEN / GITHUB_TOKEN are for github.com.

In CI (continuous integration, the automated pipelines that build and verify code), tokens are often stored in environment variables, and these verification commands may run there too. That is PlainCVE’s inference; the sources don’t state it directly.

How it works

To verify, these commands download TUF data (The Update Framework, which gh uses to fetch the signing metadata it should trust) and artifact data. They download it through gh’s shared HTTP client, which has an authentication layer that automatically adds a token to outgoing requests.

The problem was in how it chose which token to attach:

• When normalising hostnames, the code treated every *.github.com subdomain as github.com, so tuf-repo.github.com received the github.com token.
• For hosts it didn’t recognise, it fell back to the enterprise token if one was set, so that token went to the sigstore.dev and Azure hosts.

This maps to CWE-863 (Incorrect Authorization). That CWE comes from GitHub; NVD lists none of its own.

The flawed approach (conceptual illustration, not the original source code):

// Attach the github.com token if the host "looks like" GitHub, otherwise the enterprise token
func tokenFor(host string) string {
    if strings.HasSuffix(host, ".github.com") || host == "github.com" {
        return githubToken
    }
    return enterpriseToken // unknown hosts get a token too
}

The fixed approach:

// Attach a token only to an exact list of API hosts; third-party downloads get none
func tokenFor(host string) string {
    if isKnownAPIHost(host) { // exact-match list
        return tokenForHost(host)
    }
    return ""
}

GitHub says there is no evidence tokens were logged, retained or accessed by unauthorised parties. The advisory notes, however, that anyone who did obtain one of these tokens could use the permissions that token was granted, which, depending on the token’s type and permissions, could include private repositories, organization resources or enterprise administration. That is why it still recommends revoking them. For github.com users, the advisory says all authentication types are affected.

Timeline

Further reading

• Scoring differences: NVD rates it CVSS 3.1 9.1 (Critical) and GitHub (the CNA) rates it 7.4 (High). The only difference is attack complexity: NVD says Low, GitHub says High. This page uses the NVD score; some third-party sites, such as Strix, also show 9.1.
• Exploitation status: This CVE is not in CISA’s Known Exploited Vulnerabilities (KEV) catalog, and CISA’s SSVC assessment says “Exploitation: none”. EPSS was 0.289% at the time of research.
• Go Vulnerability Database: The old module path github.com/cli/cli (without v2) is listed as “all versions, no fix available”. That is an automatically generated, unreviewed entry; the actual fix is in github.com/cli/cli/v2 2.93.0.
• Not yet established: The sources don’t say which version introduced the bug or which commit or PR fixed it.
• Supply-chain angle: The bug sits in the very tools meant to protect the software supply chain (Sigstore, TUF, attestations).
• Related weakness type: CWE-863.