Skip to content

Recursive repository cloning can leak authentication tokens to non-GitHub submodule hosts

Moderate severity GitHub Reviewed Published Nov 27, 2024 in cli/cli • Updated Dec 2, 2024

Package

gomod github.com/cli/cli/v2 (Go)

Affected versions

<= 2.62.0

Patched versions

2.63.0

Description

Summary

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.

Details

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, 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 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:

  • GITHUB_ENTERPRISE_TOKEN
  • GH_ENTERPRISE_TOKEN
  • GITHUB_TOKEN when CODESPACES environment variable is set

The result being git sending authentication tokens when cloning submodules.

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

Impact

Successful exploitation could lead to a third-party using leaked authentication tokens to access privileged resources.

Remediation and mitigation

  1. Upgrade gh to 2.63.0
  2. Revoke authentication tokens used with the GitHub CLI:
  3. Review your personal security log and any relevant audit logs for actions associated with your account or enterprise

References

@andyfeller andyfeller published to cli/cli Nov 27, 2024
Published to the GitHub Advisory Database Nov 27, 2024
Reviewed Nov 27, 2024
Published by the National Vulnerability Database Nov 27, 2024
Last updated Dec 2, 2024

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Local
Attack complexity
High
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
Low

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L

EPSS score

0.043%
(11th percentile)

Weaknesses

CVE ID

CVE-2024-53858

GHSA ID

GHSA-jwcm-9g39-pmcw

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.