GitHub CLI CVE-2026-64655

Exploitation requires three concurrent conditions: (1) the attacker must successfully register a GitHub organization or repository whose name contains a dot at a position that pattern-matches the legitimate signer's name when the dot is treated as a regex wildcard (e.g., registering myXorg/my.repo to match a matcher for myXorg/my-repo); (2) the attacker must obtain valid Sigstore attestations signed from that lookalike repository, which requires it to function as a real GitHub Actions workflow environment; (3) the victim - a developer or an automated CI/CD pipeline - must invoke gh attestation verify with the --signer-repo or --signer-workflow flag specifying the legitimate signer, using a GitHub CLI version prior to 2.97.0. Limiting factors: GitHub's own namespace registration rules may block registration of certain lookalike names; the attacker cannot reuse an existing organization name and must find a dot-substitution that GitHub permits; and the victim system must be running the unpatched CLI.

The CVSS 4.0 base score of 2.1 accurately reflects the constrained real-world exploitability: AT:P (specific attack conditions present) and UI:A (active victim interaction required) together mean an attacker must pre-register a plausible lookalike repository on GitHub and have the victim actively invoke attestation verification against it. The only downstream impact is SI:L - a low integrity effect on the subsequent system (the CI/CD pipeline or policy gate relying on the verification result). Despite the low numeric score, the qualitative risk can be disproportionately high for organizations that use gh attestation verify as a hard trust gate in automated pipelines: a successful bypass could allow an attacker-signed artifact to pass as trusted. The risk is bounded by GitHub's own name-registration controls, which may or may not permit the specific lookalike string an attacker needs. No EPSS data was provided; no KEV listing exists. This is a real but targeted risk, not a broadly opportunistic one.

An attacker identifies a widely trusted signing workflow such as github/artifact-attestations-workflows/.github/workflows/attest.yml, then registers a GitHub organization named githubXartifactXattestations-workflows or, more precisely, a repository under an org where a dot substitutes for a hyphen (e.g., github/artifact.attestations-workflows). The attacker generates valid Sigstore attestations from this lookalike repository and distributes a malicious artifact alongside those attestations. When a CI/CD pipeline running an unpatched GitHub CLI executes gh attestation verify --signer-repo github/artifact-attestations-workflows, the unescaped dot in the lookalike's SAN matches the wildcard, the verification passes, and the pipeline consumes the attacker-controlled artifact as if it were trusted. No public proof-of-concept code has been identified at time of analysis.