Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

GitHub CLI allows attestation verification bypass through unescaped regex metacharactersGHSA-mm27-mwq9-fr5g

Fix: cli/cli@55dbb4d

GHSA-mm27-mwq9-fr5g is a CWE-185 vulnerability in github.com/cli/cli/v2. A fix is available for github.com/cli/cli/v2 — see the affected versions and patch details below.

Also known asCVE-2026-64655GO-2026-6767
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-mm27-mwq9-fr5g.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs27th percentile — riskier than 27% of all scored CVEsHighest risk
0.00%0.28%0.56%0.84%0.3%0.3%0.3%Sep 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐹github.com/cli/cli/v2

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

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.

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.

Remediation and Mitigation

  1. Upgrade gh to v2.97.0 or later, which escapes signer values before matching.
  2. As a workaround, use --repo or --owner flags instead of --signer-repo or --signer-workflow where applicable.
  3. Manually inspect the signing certificate SAN in attestation output to confirm the signing workflow origin.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/cli/cli/v2all versions2.97.0go get github.com/cli/cli/v2@v2.97.0

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/cli/cli/v2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/cli/cli/v2 to 2.97.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mm27-mwq9-fr5g is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### Summary 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
O3 Security · Impact-Aware SCA

Is GHSA-mm27-mwq9-fr5g in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works
GitHub CLI allows attestation verification bypass through…