GHSA-mm27-mwq9-fr5g

### 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.