CVE-2026-48501 - GitHub CLI TUF token leakage

GitHub CLI versions through 2.92.0 can attach GitHub authorization headers to non-API hosts while running gh attestation, gh release verify, or gh release verify-asset. The affected commands fetch TUF and artifact metadata from hosts outside the normal GitHub API boundary; vulnerable CLI versions can send github.com or enterprise tokens to those hosts during ordinary verification workflows.

For security automation, this matters most in CI images, developer containers, release verification jobs, provenance checks, and agent workspaces that pin or install gh. A codebase may be exposed even if it does not import github.com/cli/cli/v2 as a Go dependency, because the vulnerable surface is often a packaged CLI binary used by scripts.

GitHub’s CNA severity is High. NVD currently reports a Critical CVSS score for the same CVE. The patch path is the same in both sources: update GitHub CLI to 2.93.0+.

When to use it

Use this recipe when a repository installs, pins, vendors, wraps, or packages GitHub CLI in developer containers, CI images, release tooling, provenance checks, SLSA/SBOM workflows, agent workspaces, or self-hosted runner bootstrap scripts. It is most important when gh attestation, gh release verify, or gh release verify-asset runs with GitHub tokens in the environment.

Use it to upgrade the CLI and reduce token blast radius without reproducing the header leak with live credentials.

Inputs

  • Dockerfiles, devcontainers, GitHub Actions workflows, runner bootstrap scripts, release scripts, install scripts, package pins, checksums, SBOMs, base-image docs, vendored binaries, and wrappers that install or invoke gh.
  • Resolved gh --version evidence from refreshed images, scripts, and release containers.
  • Usage of gh attestation, gh release verify, gh release verify-asset, SLSA/provenance verification, release promotion, binary verification, SBOM checks, or agent release review.
  • Secret names, not values, present in command environments: GH_TOKEN, GITHUB_TOKEN, GH_ENTERPRISE_TOKEN, GITHUB_ENTERPRISE_TOKEN, GitHub App tokens, PATs, OAuth tokens, and persisted gh auth state.
  • Token ownership and audit-log review paths for account, organization, and enterprise activity after affected commands ran.

Affected versions

  • Vulnerable: gh <=2.92.0
  • Fixed: gh 2.93.0+
  • Affected package coordinate: github.com/cli/cli/v2
  • Affected commands: gh attestation, gh release verify, and gh release verify-asset

Indicator-of-exposure

  • The repository installs, pins, vendors, or builds GitHub CLI <=2.92.0 in a Dockerfile, devcontainer, CI image, runner bootstrap script, release tool, or developer setup script.
  • CI, release, artifact-verification, provenance, SLSA, or SBOM workflows run gh attestation, gh release verify, or gh release verify-asset.
  • The command environment includes GH_TOKEN, GITHUB_TOKEN, GH_ENTERPRISE_TOKEN, GITHUB_ENTERPRISE_TOKEN, persisted gh auth state, a personal access token, a GitHub App token, or an enterprise-scoped token.
  • The same runner or agent workspace can access private repositories, organization settings, package registries, release assets, or enterprise administration APIs.

Quick checks:

rg -n "gh (attestation|release verify|release verify-asset)|github-cli|cli/cli|gh_[0-9]|GH_TOKEN|GITHUB_TOKEN|GH_ENTERPRISE_TOKEN|GITHUB_ENTERPRISE_TOKEN|gh auth|attest|verify-asset" .
gh --version
gh auth status

Windows:

rg -n "gh (attestation|release verify|release verify-asset)|github-cli|cli/cli|gh_[0-9]|GH_TOKEN|GITHUB_TOKEN|GH_ENTERPRISE_TOKEN|GITHUB_ENTERPRISE_TOKEN|gh auth|attest|verify-asset" .
gh --version
gh auth status

Do not run gh auth token, print environment variables, or capture live HTTP authorization headers during triage.

Remediation strategy

  • Upgrade every repository-controlled GitHub CLI installation to 2.93.0+.
  • Refresh Dockerfiles, devcontainers, CI bootstrap scripts, runner images, package manager pins, checksums, SBOMs, and release tool documentation.
  • Add a CI guard where this repo owns verification jobs: fail before running affected commands if gh --version resolves below 2.93.0.
  • Run attestation and release verification in a least-privilege token context. Avoid GH_ENTERPRISE_TOKEN or long-lived PATs in jobs that only need public GitHub verification.
  • If upgrade cannot deploy immediately, disable the affected gh commands or run them only in a tokenless environment until the fixed CLI is available.
  • Rotate long-lived GitHub CLI, PAT, GitHub App, and enterprise tokens that were present when the affected commands ran. Review account, organization, and enterprise audit logs for unexpected activity.

The prompt

You are remediating CVE-2026-48501 / GHSA-8xvp-7hj6-mcj9, a GitHub CLI
authorization-header leakage issue in attestation and release verification
commands. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades every repository-controlled
  GitHub CLI installation, blocks vulnerable verification jobs, adds safe
  regression checks, and documents operator token cleanup, or
- TRIAGE.md if this repository does not own any affected GitHub CLI
  installation, workflow, image, or wrapper.

## Rules

- Scope only CVE-2026-48501 / GHSA-8xvp-7hj6-mcj9.
- Treat GitHub tokens, OAuth tokens, GitHub App tokens, `GITHUB_TOKEN`, PATs,
  enterprise tokens, release assets, audit logs, and private repository names
  as sensitive.
- Do not print tokens, run `gh auth token`, capture authorization headers,
  proxy live GitHub traffic, or reproduce the leak with real credentials.
- Do not remove release verification or provenance checks to make the alert go
  away. Upgrade or safely contain them.
- Do not broaden GitHub token scopes while changing verification jobs.
- Do not auto-merge.

## Steps

1. Inventory every GitHub CLI installation controlled by this repository:
   Dockerfiles, devcontainers, GitHub Actions workflows, self-hosted runner
   bootstrap scripts, release scripts, install scripts, package manager pins,
   checksums, SBOMs, base image docs, and vendored binaries.
2. Determine every resolved `gh` version. A target is vulnerable if it resolves
   to `2.92.0` or earlier.
3. Search for affected command usage:
   - `gh attestation`;
   - `gh release verify`;
   - `gh release verify-asset`;
   - wrappers around artifact provenance, SLSA, release promotion, binary
     verification, SBOM verification, or agent release review.
4. Search the command environments for token exposure:
   `GH_TOKEN`, `GITHUB_TOKEN`, `GH_ENTERPRISE_TOKEN`,
   `GITHUB_ENTERPRISE_TOKEN`, persisted `gh auth` config, GitHub App tokens,
   PATs, release tokens, organization tokens, and enterprise-scoped secrets.
   Record secret names only; never print values.
5. If the repository neither installs GitHub CLI nor runs the affected
   commands, stop with `TRIAGE.md` listing checked files and the external owner
   if another platform image supplies `gh`.
6. Upgrade all controlled GitHub CLI pins to `2.93.0+`. Refresh checksums,
   image layers, generated lockfiles, SBOMs, dependency reports, docs, and
   runner image metadata.
7. Add a preflight guard to affected jobs or wrappers where practical:
   - parse `gh --version`;
   - fail closed below `2.93.0`;
   - emit a non-secret remediation message;
   - run before any affected `gh` command receives a token-bearing
     environment.
8. Reduce token blast radius:
   - avoid long-lived PATs for verification jobs;
   - avoid `GH_ENTERPRISE_TOKEN` unless the target host is a known enterprise
     server;
   - prefer short-lived, read-only, repository-scoped tokens;
   - keep attestation verification jobs separate from release publishing jobs;
   - clear persisted `gh auth` state from shared runner images and agent
     workspaces.
9. If this repository vendors or wraps `github.com/cli/cli/v2` code, upgrade
   the module and add unit tests that prove authorization headers are only sent
   to the intended GitHub API or configured GHES API hosts. Do not perform live
   network tests with real tokens.
10. Add regression coverage that is safe for reviewers:
    - CI image or install script resolves `gh >=2.93.0`;
    - affected commands fail closed when the detected CLI is too old;
    - verification jobs do not expose long-lived PAT or enterprise-token
      secrets unless explicitly justified;
    - docs and SBOMs name the fixed CLI version.
11. Add a PR body section named `CVE-2026-48501 operator actions` that states:
    - GitHub CLI versions before and after;
    - where `gh attestation`, `gh release verify`, or
      `gh release verify-asset` run;
    - which token-bearing environments were present by secret name only;
    - whether any long-lived PAT, GitHub App, OAuth, or enterprise token should
      be revoked and reissued;
    - which account, organization, and enterprise audit logs should be reviewed;
    - any temporary tokenless or disabled verification containment still in
      place.
12. Run relevant validation: shellcheck or script tests, workflow lint,
    container build, `gh --version` checks in refreshed images, unit tests for
    wrappers, SBOM refresh, dependency/security scans, and a dry-run or
    non-secret verification path available in this repository.
13. Use PR title:
    `fix(sec): remediate CVE-2026-48501 in GitHub CLI usage`.

## Stop conditions

- No repository-controlled GitHub CLI installation, image, or affected command
  usage exists.
- The vulnerable `gh` binary is supplied only by an external runner image or
  platform outside this repository's ownership; document the owning team and
  required fixed version.
- Verification depends on production-only tokens, private audit logs, or live
  header capture.
- A fixed GitHub CLI cannot be installed without a broader base-image or runner
  migration.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No repository-controlled Dockerfile, devcontainer, runner image, setup script, package pin, SBOM, or release tool resolves GitHub CLI below 2.93.0.
  • Jobs that run gh attestation, gh release verify, or gh release verify-asset have a preflight version guard or a documented platform-level guarantee.
  • The PR does not print token values, capture live headers, or weaken attestation/release verification.
  • Long-lived and enterprise-scoped token exposure is explicitly reviewed, with rotation guidance when affected commands previously ran.
  • Generated artifacts, checksums, image metadata, and documentation agree on the fixed gh version.

Watch for

  • Updating a developer install script while CI, self-hosted runner images, or release containers still pin gh <=2.92.0.
  • Treating this as only a Go module dependency when the exposed surface is a CLI binary used by scripts.
  • Leaving GH_ENTERPRISE_TOKEN in public GitHub verification jobs that do not target GHES.
  • Removing attestation or release verification instead of upgrading the CLI.
  • Logging secret names together with enough context to reveal private repository, organization, or enterprise details unnecessarily.

Output contract

Return one of:

  • A reviewer-ready PR/change request that upgrades every controlled GitHub CLI installation to 2.93.0+, adds preflight guards before affected commands, refreshes checksums/images/SBOMs/docs, reduces token blast radius, and documents operator token cleanup.
  • TRIAGE.md when no controlled GitHub CLI installation, image, workflow, wrapper, or affected command usage exists.

The output must list versions before/after, locations where affected commands run, token-bearing environments by secret name only, preflight guards added, validation commands, artifacts refreshed, and rotation/audit-log review actions. It must not print tokens, run gh auth token, capture live authorization headers, proxy production traffic, remove provenance checks, or broaden token scopes.

References