CVE-2024-53858: GitHub CLI Token Leakage Vulnerability

CVE-2024-53858 Overview

A security vulnerability has been identified in the GitHub CLI (gh) that could leak authentication tokens when cloning repositories containing git submodules hosted outside of GitHub.com and ghe.com. This information disclosure vulnerability stems from how several gh commands handle credential retrieval for non-GitHub hosts, potentially exposing sensitive authentication tokens to untrusted servers.

Critical Impact

Authentication tokens including GITHUB_ENTERPRISE_TOKEN, GH_ENTERPRISE_TOKEN, and GITHUB_TOKEN may be inadvertently sent to external hosts when cloning repositories with submodules, potentially compromising GitHub accounts and enterprise environments.

Affected Products

• GitHub CLI versions prior to 2.63.0
• Systems using gh repo clone with repositories containing external submodules
• Systems using gh repo fork and gh pr checkout with external submodules

Discovery Timeline

• 2024-11-27 - CVE-2024-53858 published to NVD
• 2024-11-27 - Last updated in NVD database

Technical Details for CVE-2024-53858

Vulnerability Analysis

This vulnerability represents an information disclosure flaw (CWE-200) in the GitHub CLI's credential helper implementation. When users execute commands like gh repo clone, gh repo fork, or gh pr checkout on repositories containing submodules hosted on non-GitHub domains, the CLI incorrectly treats these external hosts as GitHub Enterprise Server instances.

The vulnerable behavior occurs because the GitHub CLI invokes git with the credential.helper configuration variable set to retrieve authentication tokens for any host encountered during the cloning process. Prior to version 2.63.0, the CLI does not properly restrict which hosts should receive authentication credentials.

The token retrieval follows a specific priority order:

1. GITHUB_ENTERPRISE_TOKEN environment variable
2. GH_ENTERPRISE_TOKEN environment variable
3. GITHUB_TOKEN when the CODESPACES environment variable is set
4. Host-specific tokens from system-secured storage

This means that when cloning a repository with submodules pointing to attacker-controlled servers, the CLI may inadvertently transmit valid GitHub authentication tokens to those external hosts.

Root Cause

The root cause lies in the overly permissive credential helper configuration within the GitHub CLI. The application failed to implement proper host validation before sourcing and transmitting authentication tokens. Any host encountered during git operations was treated as a potential GitHub Enterprise Server instance, triggering credential retrieval and transmission without verifying the destination host's legitimacy.

Attack Vector

An attacker could exploit this vulnerability by creating a malicious repository on GitHub that contains submodule references pointing to attacker-controlled external servers. When a victim uses the GitHub CLI to clone, fork, or checkout a pull request from this repository, the CLI would automatically attempt to authenticate with the attacker's server using the victim's GitHub tokens.

The attack requires local access context and user interaction (the victim must clone the malicious repository), but requires no privileges on the victim's system. The attacker's server would receive the authentication tokens in the HTTP headers, allowing them to potentially access the victim's GitHub account, repositories, and enterprise resources.

Detection Methods for CVE-2024-53858

Indicators of Compromise

• Unexpected network connections to external hosts during gh clone operations
• Authentication tokens appearing in access logs of non-GitHub servers
• Unauthorized API calls or repository access in GitHub audit logs
• Environment variables GITHUB_ENTERPRISE_TOKEN or GH_ENTERPRISE_TOKEN being accessed by unexpected processes

Detection Strategies

• Monitor outbound network traffic during git clone operations for connections to unexpected hosts
• Review GitHub personal security logs for unusual authentication events or API access patterns
• Audit enterprise GitHub logs for actions that don't correlate with expected user activity
• Implement network security monitoring to detect credential transmission to non-GitHub domains

Monitoring Recommendations

• Enable verbose logging for GitHub CLI operations to track credential helper invocations
• Configure network monitoring rules to alert on git credential transmissions to non-approved hosts
• Review and monitor the credential.helper configuration in git settings
• Set up alerts for token usage from unexpected IP addresses or geographic locations

How to Mitigate CVE-2024-53858

Immediate Actions Required

• Upgrade GitHub CLI to version 2.63.0 or later immediately
• Revoke and regenerate all authentication tokens previously used with the GitHub CLI
• Review personal security logs and enterprise audit logs for unauthorized actions
• Audit repositories recently cloned for suspicious submodule configurations

Patch Information

GitHub has released version 2.63.0 of the GitHub CLI which addresses this vulnerability by limiting the hosts for which gh acts as a credential helper. The patch ensures that authentication tokens are only sourced and transmitted to GitHub.com and ghe.com domains. Additionally, GITHUB_TOKEN will now only be used for GitHub.com and ghe.com hosts, preventing token leakage to external servers.

For detailed patch information, refer to the GitHub Security Advisory GHSA-jwcm-9g39-pmcw.

Workarounds

• Avoid cloning repositories with submodules from untrusted sources until upgraded
• Manually inspect .gitmodules files before cloning repositories to verify submodule URLs
• Use --recurse-submodules=no flag when cloning to prevent automatic submodule initialization
• Temporarily unset GitHub token environment variables before cloning untrusted repositories

# Verify current GitHub CLI version
gh --version

# Upgrade GitHub CLI to patched version
# On macOS with Homebrew
brew upgrade gh

# On Windows with Chocolatey
choco upgrade gh

# Clone without automatically fetching submodules
gh repo clone owner/repo -- --recurse-submodules=no

# Manually review submodules before initialization
cat .gitmodules