GitHub CLI allows attestation verification bypass through unescaped regex metacharacters

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.