Summary
GitHub CLI allows attestation verification bypass through unescaped regex metacharacters
A security vulnerability has been identified in GitHub CLI that could allow attestation verification bypass when using gh attestation verify with --signer-repo or --signer-workflow flags. GitHub CLI builds the certificate matcher from these flag values without escaping regex metacharacters, so a repository or workflow name is treated as a regular expression rather than a literal string. GitHub permits characters such as . in organization, repository, and workflow path names, and . is a regex wildcard, so a malicious actor can create a lookalike name that satisfies a matcher intended for a different, trusted signer.
Details
GitHub CLI constructs a regular expression from the --signer-repo and --signer-workflow values and matches it against the signing certificate's SAN (Subject Alternative Name) during Sigstore attestation verification. The user-supplied value is interpolated into the pattern without escaping regex metacharacters, so any metacharacter permitted in a GitHub path is interpreted as regex syntax instead of a literal character.
The most practical case is . , which GitHub allows in org/repo names and is a regex wildcard meaning "any single character." For example, an attacker-controlled repository named:
github/artifact.attestations-workflows
matches a verifier configured for the trusted signer:
github/artifact-attestations-workflows
because the unescaped . in the constructed pattern matches the - in the attacker's name (and any other single character at that position). This affected the --signer-repo and --signer-workflow flags but did not affect the --repo and --owner flags which include an exact string comparison.
In v2.97.0, the GitHub CLI escapes the user-supplied signer values before they are incorporated into the SAN matcher, so they are matched as literal strings.
Remediation and Mitigation
- Upgrade
ghtov2.97.0or later, which escapes signer values before matching. - As a workaround, use
--repoor--ownerflags instead of--signer-repoor--signer-workflowwhere applicable. - Manually inspect the signing certificate SAN in attestation output to confirm the signing workflow origin.
Impact
The practical impact is limited, exploitation requires the attacker to create a plausible lookalike repository name and produce valid Sigstore attestations from it. This could undermine supply chain verification for CI/CD pipelines or policy gates that use these flags to pin trust to a specific signing workflow.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-64655? CVE-2026-64655 is a low-severity security vulnerability in github.com/cli/cli/v2 (go), affecting versions < 2.97.0. It is fixed in 2.97.0.
- Which versions of github.com/cli/cli/v2 are affected by CVE-2026-64655? github.com/cli/cli/v2 (go) versions < 2.97.0 is affected.
- Is there a fix for CVE-2026-64655? Yes. CVE-2026-64655 is fixed in 2.97.0. Upgrade to this version or later.
- Is CVE-2026-64655 exploitable, and should I be worried? Whether CVE-2026-64655 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-64655 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-64655? Upgrade
github.com/cli/cli/v2to 2.97.0 or later.