CVE-2024-50338: Git Credential Manager Info Disclosure

CVE-2024-50338 Overview

Git Credential Manager (GCM) is a secure Git credential helper built on .NET that runs on Windows, macOS, and Linux. A critical vulnerability exists in how GCM handles newline characters compared to Git itself. The Git credential protocol is text-based over standard input/output, consisting of key-value pairs in the format key=value. While Git's documentation restricts the use of NUL (\0) characters and newlines in keys or values, a mismatch in newline treatment between Git and GCM allows attackers to craft malicious remote URLs that can capture credentials for other Git remotes.

The vulnerability stems from the .NET StreamReader class used by GCM, which considers LF, CRLF, and CR as valid line endings, whereas Git only considers LF and CRLF. This discrepancy means that a single carriage return (CR) character is treated as a newline by GCM but not by Git, enabling credential injection attacks.

Critical Impact

Attackers can craft malicious repositories that, when cloned or interacted with, capture credentials intended for other Git remotes. The attack is particularly dangerous with recursive cloning of repositories containing submodules.

Affected Products

• Git Credential Manager versions prior to 2.6.1
• Git Credential Manager on Windows, macOS, and Linux platforms
• Applications using GCM with the --recursive clone option for submodules

Discovery Timeline

• 2025-01-14 - CVE CVE-2024-50338 published to NVD
• 2025-01-14 - Last updated in NVD database

Technical Details for CVE-2024-50338

Vulnerability Analysis

This vulnerability (CWE-200: Information Exposure) exploits the inconsistent handling of newline characters between Git and Git Credential Manager. When Git reads from standard input for the credential protocol, it uses strbuf_getline which calls strbuf_getdelim_strip_crlf, treating both LF and CRLF as valid newline characters. Git also validates that no newline exists in credential values by checking for the line-feed character (LF, \n).

However, Git Credential Manager uses the .NET standard library StreamReader class with its ReadLineAsync method, which considers LF, CRLF, and CR as valid line endings. This creates a parsing mismatch where a standalone carriage return (CR, \r) is interpreted as a newline by GCM but not by Git.

An attacker can exploit this by embedding CR characters in a malicious remote URL. When a victim clones or interacts with the malicious repository, GCM parses the input differently than Git intended, allowing the attacker to inject additional credential protocol fields that redirect authentication to an attacker-controlled remote.

Root Cause

The root cause is the inconsistent line ending treatment between Git's C implementation and the .NET StreamReader class used by GCM. Git's strbuf_getdelim_strip_crlf function in the credential parsing code specifically handles LF and CRLF sequences, but the .NET StreamReader.ReadLineAsync method additionally recognizes standalone CR characters as line terminators. This implementation difference in the .NET runtime source code allows credential protocol injection through carefully crafted URLs containing CR characters.

Attack Vector

The attack vector is network-based and requires user interaction. An attacker creates a malicious Git repository with a remote URL containing embedded CR characters. When a victim performs any Git operation requiring authentication (clone, fetch, push), the malicious URL causes GCM to interpret additional credential fields injected by the attacker.

The attack is significantly amplified when using the --recursive clone option, as submodule URLs are not visible to the user before cloning begins. An attacker can hide malicious submodule configurations that redirect credentials to attacker-controlled endpoints.

The attack flow works as follows: the victim initiates a clone operation, Git sends credential request to GCM via standard input, the malicious URL containing CR characters causes GCM to parse additional injected fields, and GCM may then send credentials to an attacker-controlled remote instead of the intended destination.

Detection Methods for CVE-2024-50338

Indicators of Compromise

• Git remote URLs containing carriage return (\r or %0D) characters in repository configurations
• Unexpected credential prompts when cloning repositories from untrusted sources
• Authentication requests to unknown or suspicious Git hosting endpoints
• Anomalous network connections to non-standard Git server addresses during clone operations

Detection Strategies

• Monitor Git operations for remote URLs containing embedded control characters (especially CR/\r)
• Implement network monitoring to detect authentication traffic to unexpected Git endpoints
• Review .gitmodules files in repositories for suspicious submodule URLs before recursive cloning
• Deploy endpoint detection to identify Git Credential Manager versions prior to 2.6.1

Monitoring Recommendations

• Enable verbose logging for Git operations to capture credential helper interactions
• Monitor for unusual authentication patterns where credentials are requested for unexpected remotes
• Implement repository scanning policies to inspect .gitmodules and remote configurations
• Set up alerts for Git clone operations with the --recursive flag from untrusted sources

How to Mitigate CVE-2024-50338

Immediate Actions Required

• Upgrade Git Credential Manager to version 2.6.1 or later immediately
• Avoid using the --recursive clone option when cloning repositories from untrusted sources
• Manually inspect .gitmodules files and remote URLs in repositories before interacting with them
• Review recent Git operations for any suspicious credential requests or unexpected authentication prompts

Patch Information

The vulnerability has been patched in Git Credential Manager version 2.6.1. Users should upgrade immediately by downloading the latest release from the official GitHub release page. The fix addresses the newline handling mismatch by properly validating input in the StreamExtensions implementation. For detailed information about the security fix, see the GitHub Security Advisory GHSA-86c2-4x57-wc8g.

Workarounds

• Only interact with trusted remote repositories until the patch can be applied
• Clone repositories without the --recursive flag, then manually inspect submodule URLs before initializing them
• Use git submodule init followed by manual URL inspection before running git submodule update
• Consider using alternative credential helpers temporarily if immediate upgrade is not possible

# Safe submodule cloning workflow (workaround)
# Clone without recursive flag
git clone https://example.com/repo.git

# Inspect submodule URLs before initializing
cd repo
cat .gitmodules

# Only after verification, initialize submodules
git submodule init
git submodule update