Summary
GitHub CLI incorrectly includes an authorization header in API requests to TUF repository mirrors via gh attestation, gh release verify, and gh release verify-asset commands.
Affected users:
- Authenticated github.com users who previously ran gh attestation commands, gh release verify, or gh release verify-asset: the github.com token was included in requests to tuf-repo.github.com, a GitHub Pages domain that is not a GitHub API endpoint. All authentication types are affected. - Users with GHENTERPRISETOKEN or GITHUBENTERPRISETOKEN set who previously ran gh attestation commands, gh release verify, or gh release verify-asset: the enterprise token was included in requests to external hosts tuf-repo-cdn.sigstore.dev and tmaproduction.blob.core.windows.net. These hosts are not operated by GitHub.
Details
The CLI uses a shared HTTP client with an authentication layer that automatically attaches tokens to outgoing requests. This layer lacks accurate host detection and can incorrectly attribute the target host, providing it with a token it should never receive.
Specifically, the host normalization logic collapses any .github.com subdomain to github.com, so a request to tuf-repo.github.com (a GitHub Pages site, not a GitHub API endpoint) is treated as a request to github.com and receives the user's github.com token. For hosts that don't match github.com or a known GHES instance at all, the resolver falls back to GHENTERPRISETOKEN if set.
The gh attestation, gh release verify and gh release verify-asset commands fetch data from several external hosts as part of their normal operation (TUF metadata from tuf-repo.github.com and tuf-repo-cdn.sigstore.dev, artifact bundles from Azure Blob Storage). Because these requests go through the same authenticated HTTP client, the token is sent to all of them.
Impact
Tokens were transmitted in HTTP headers to the listed hosts during normal gh attestation, gh release verify, and gh release verify-asset operations. There is no evidence that tokens were logged, retained, or accessed by unauthorized parties. If a token were captured, it would grant the same access as the token holder, potentially including private repositories, organization resources, or enterprise administration depending on token type and permissions.
Remediation and mitigation
1. Revoke authentication tokens used with the GitHub CLI: - Personal access tokens - GitHub CLI OAuth app 2. Upgrade gh to 2.93.0. 3. Review personal security logs and any relevant audit logs for actions associated with personal or enterprise accounts.
Summary
A security vulnerability has been identified in GitHub CLI that could allow terminal escape sequence injection when users view GitHub Actions workflow logs using gh run view --log or gh run view --log-failed.
Details
The vulnerability stems from the way GitHub CLI handles raw Actions log output. The gh run view --log and gh run view --log-failed commands stream workflow log lines to stdout or the configured pager without sanitizing terminal control sequences. An attacker who can influence GitHub Actions log content, for example via a PR triggered workflow, can embed escape sequences that are replayed in the user's terminal when they inspect the run.
Depending on the victim's terminal emulator, injected sequences could change the window title, manipulate on screen content, or in some terminal emulators (such as screen) potentially execute arbitrary commands.
In 2.92.0, GitHub CLI sanitizes terminal control sequences in Actions log output before writing to the terminal.
PoC
Create a workflow that emits terminal escape sequences in its log output:
yaml name: Escape Sequence PoC
on: workflowdispatch:
jobs: emit-escape-sequences: runs-on: ubuntu-latest steps: - name: Emit terminal escape sequences run: | # OSC title set printf 'ESCAPEMARKERSTART \033]0;HIJACKEDTITLE\007 ESCAPEMARKEREND\n' # CSI color printf 'ESCAPEMARKERSTART \033[31mREDTEXT\033[0m ESCAPEMARKEREND\n' # Screen title set (enables command execution in screen terminal) printf 'ESCAPEMARKERSTART \033k;malicious command;\033\\ ESCAPEMARKEREND\n'
Then trigger the workflow and view its logs:
bash gh workflow run 'Escape Sequence PoC' gh run view <runid> --log
On vulnerable versions, the raw ESC bytes (0x1b) are passed through to the terminal unsanitized. On 2.92.0 and later, escape sequences are stripped and only the safe visible text is displayed.
Impact
An attacker who can control GitHub Actions workflow output can inject terminal escape sequences into a maintainer's terminal session when they inspect the run with gh run view --log or gh run view --log-failed. The practical impact depends on the victim's terminal emulator.
Remediation and Mitigation
1. Upgrade gh to 2.92.0 2. Pipe log output through a sanitizer (e.g., gh run view --log | cat -v) as a workaround on older versions 3. Exercise caution when viewing logs from untrusted workflow runs
Summary
A security vulnerability has been identified in GitHub CLI that could allow remote code execution (RCE) when users connect to a malicious Codespace SSH server and use the gh codespace ssh or gh codespace logs commands.
Details
The vulnerability stems from the way GitHub CLI handles SSH connection details when executing commands. When developers connect to remote Codespaces, they typically use a SSH server running within a devcontainer, often provided through the default devcontainer image. GitHub CLI retrieves SSH connection details, such as remote username, which is used in executing ssh commands for gh codespace ssh or gh codespace logs commands.
This exploit occurs when a malicious third-party devcontainer contains a modified SSH server that injects ssh arguments within the SSH connection details. gh codespace ssh and gh codespace logs commands could execute arbitrary code on the user's workstation if the remote username contains something like -oProxyCommand="echo hacked" #. The -oProxyCommand flag causes ssh to execute the provided command while # shell comment causes any other ssh arguments to be ignored.
In 2.62.0, the remote username information is being validated before being used.
Impact
Successful exploitation could lead to arbitrary code execution on the user's workstation, potentially compromising the user's data and system.
Remediation and Mitigation
1. Upgrade gh to 2.62.0 2. Exercise caution when using custom devcontainer images, prefer default or pre-built devcontainers from trusted sources.