The gh cli is GitHub’s official command line tool. A security vulnerability has been identified in the GitHub CLI that could leak authentication tokens when cloning repositories containing git submodules hosted outside of GitHub.com and ghe.com. This vulnerability stems from several gh commands used to clone a repository with submodules from a non-GitHub host including gh repo clone, gh repo fork, and gh pr checkout. These GitHub CLI commands invoke git with instructions to retrieve authentication tokens using the credential.helper configuration variable for any host encountered. Prior to version 2.63.0, hosts other than GitHub.com and ghe.com are treated as GitHub Enterprise Server hosts and have tokens sourced from the following environment variables before falling back to host-specific tokens stored within system-specific secured storage: 1. GITHUB_ENTERPRISE_TOKEN, 2. GH_ENTERPRISE_TOKEN and 3. GITHUB_TOKEN when the CODESPACES environment variable is set. The result being git sending authentication tokens when cloning submodules. In version 2.63.0, these GitHub CLI commands will limit the hosts for which gh acts as a credential helper to source authentication tokens. Additionally, GITHUB_TOKEN will only be used for GitHub.com and ghe.com. Users are advised to upgrade. Additionally users are advised to revoke authentication tokens used with the GitHub CLI and to review their personal security log and any relevant audit logs for actions associated with their account or enterprise
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
There are many different kinds of mistakes that introduce information exposures. The severity of the error can range widely, depending on the context in which the product operates, the type of sensitive information that is revealed, and the benefits it may provide to an attacker. Some kinds of sensitive information include:
Information might be sensitive to different parties, each of which may have their own expectations for whether the information should be protected. These parties include:
Information exposures can occur in different ways:
It is common practice to describe any loss of confidentiality as an “information exposure,” but this can lead to overuse of CWE-200 in CWE mapping. From the CWE perspective, loss of confidentiality is a technical impact that can arise from dozens of different weaknesses, such as insecure file permissions or out-of-bounds read. CWE-200 and its lower-level descendants are intended to cover the mistakes that occur in behaviors that explicitly manage, store, transfer, or cleanse sensitive information.