GitHub CLI (gh) is GitHub's official command line tool. Versions 2.28.0 through 2.97.0 bind the local listener created by gh codespace ports forward to all available network interfaces by default. While port forwarding is active, a service in a Codespace can therefore become reachable through the user's non-loopback local IP addresses by other hosts that can route to the user's machine. This behavior does not change the GitHub-side visibility of the Codespaces port. Instead, it exposes the forwarded service through a wildcard-bound listener on the user's local machine, even when the source Codespaces port remains private. Exploitation requires a network-adjacent attacker to reach the victim's machine while forwarding is active. This issue is fixed in version 2.98.0.

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.

GitHub CLI (gh) is GitHub's official command line tool. Prior to version 2.97.0, multiple GitHub CLI commands printed externally controlled gist, API, pull request, release, codespace, skill, or agent-task content without neutralizing terminal escape sequences. An attacker who can influence that content can embed escape sequences that are interpreted by the terminal of a user who runs an affected command, with impact ranging from cosmetic manipulation of the title or on-screen content to, on some terminal emulators, command execution. This extends the same class of issue as CVE-2026-45803—which addressed only gh run view --log—to the other affected command paths. This issue is fixed in version 2.97.0.

Summary

A path traversal vulnerability has been identified in the GitHub CLI where some HTTP request URLs, REST API calls in particular, were built without properly escaping their variable path components. A value containing URL path metacharacters can alter the request path and cause gh to address a different resource than intended.

Details

Not all request URLs in the codebase were built with proper escaping of their variable path components. When a component is interpolated into the path without percent encoding, and that component contains URL path metacharacters, it breaks out of its intended segment and changes the effective request path.

In 2.97.0, request URLs are constructed in a safe manner, so a variable component can no longer escape its intended segment.

Impact

An attacker who can control a value that flows into a request path can cause gh to send the request to a different API endpoint than intended. This can lead the CLI to read or act on a resource other than the one the user meant to target.

Remediation and Mitigation

1. Upgrade gh to 2.97.0. 2. Be cautious when running gh against untrusted repositories or inputs whose names you do not control.

Summary

A security vulnerability has been identified in GitHub CLI where gh auth status could potentially print a portion of the authentication token in plaintext, depending on the lexical structure of the token.

Affected users: - Authenticated users who ran gh auth status (without the --show-token flag) with a token type whose format contains an underscore after the prefix. This includes fine-grained personal access tokens (githubpat) and GitHub App installation/user access tokens (ghs, ghu, e.g., ghs<APPID><JWT>), including the Actions GITHUBTOKEN. Classic tokens such as gho and ghp have an underscore-free body and are not affected.

Details

The vulnerability stems from the way GitHub CLI masks the authentication token when reporting authentication state:

1. A user runs gh auth status without --show-token, expecting the token to be fully masked. 2. The masking logic redacts only the characters that follow the last underscore in the token, instead of redacting everything after the token prefix. 3. The partially masked token is written to the command output, where it can be captured or shared.

Because gh auth status is a diagnostic command commonly run interactively and inside automated environments, the leaked token characters can end up in CI/CD job logs, terminal scrollback, screen recordings, screenshots, or pasted output shared in bug reports and support requests.

In v2.97.0, GitHub CLI fully masks the token in gh auth status output, preserving only the known token prefix and redacting the remainder unless --show-token is explicitly provided.

Impact

Running gh auth status in a context where the output is captured, logged, or shared could leak a portion of an affected token. The affected token types are fine-grained personal access tokens (githubpat) and GitHub App installation/user access tokens (ghs, ghu, e.g., ghs<APPID><JWT>), including the Actions GITHUBTOKEN. Installation and Actions tokens are short-lived, which narrows the window in which a recovered token could be reused. See GitHub credential types.

Remediation and Mitigation

1. Upgrade gh to v2.97.0. 2. Rotate any affected token whose masked gh auth status output may have been captured or shared: - Fine-grained personal access tokens (githubpat): regenerate the token from your account settings. See Managing your personal access tokens. - GitHub App installation/user access tokens (ghs, ghu, e.g., ghs<APPID><JWT>): these are short-lived and rotate automatically (See GitHub credential types). If you believe a token was captured while still valid, you can revoke it immediately using the Revoke an installation access token REST endpoint (DELETE /installation/token). To cut off a third-party app's access more broadly, suspend or uninstall the app from the web UI. See Reviewing and modifying installed GitHub Apps. - Actions GITHUBTOKEN: this token is automatically invalidated when the job finishes, so no manual revocation is normally required. See GitHub credential types. 3. Until you can upgrade, avoid running gh auth status in contexts where the output is captured or shared, and manually redact the token line before sharing any output.

GitHub CLI (gh) is GitHub’s official command line tool. From 2.10.0 through 2.95.0, connecting to a malicious Codespace with gh codespace jupyter can allow command execution because the command opens a JupyterLab URL supplied by a process inside the Codespace without validating that it is a loopback HTTP or HTTPS address, allowing a crafted vscode:// or vscode-insiders:// URL to be handed to VS Code. This issue is fixed in version 2.96.0.