CVE-2025-48064 in GitHub
Summary
by MITRE • 05/21/2025
GitHub Desktop is an open-source, Electron-based GitHub app designed for git development. Prior to version 3.4.20-beta3, an attacker convincing a user to view a file in a commit of their making in the history view can cause information disclosure by means of Git attempting to access a network share. This affects GitHub Desktop users on Windows that view malicious commits in the history view. macOS users are not affected. When viewing a file diff in the history view GitHub Desktop will call `git log` or `git diff` with the object id (SHA) of the commit, the name of the file, and the old name of the file if the file has been renamed. As a security precaution Git will attempt to fully resolve the old and new path via `realpath`, traversing symlinks, to ensure that the resolved paths reside within the repository working directory. This can lead to Git attempting to access a path that resides on a network share (UNC path) and in doing so Windows will attempt to perform NTLM authentication which passes information such as the computer name, the currently signed in (Windows) user name, and an NTLM hash. GitHub Desktop 3.4.20 and later fix this vulnerability. The beta channel includes the fix in 3.4.20-beta3. As a workaround to use until upgrading is possible, only browse commits in the history view that comes from trusted sources.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 05/21/2025
This vulnerability affects GitHub Desktop versions prior to 3.4.20-beta3 on Windows systems, creating a potential information disclosure risk through improper path resolution during git operations. The flaw occurs when users view malicious commits in the history view, specifically when Git attempts to resolve file paths using the realpath function. This function traverses symbolic links to ensure paths remain within the repository working directory, but fails to properly restrict access to network shares. The vulnerability exploits the Windows file system behavior where accessing UNC (Universal Naming Convention) paths triggers automatic NTLM authentication, which inadvertently exposes sensitive information including computer names, currently logged-in user names, and NTLM hash values. The attack vector specifically targets the git log and git diff commands executed by GitHub Desktop when displaying file differences in commit history, where the object ID (SHA) of commits, file names, and previous file names are passed to Git. This represents a classic path traversal vulnerability that leverages system-level file resolution mechanisms rather than application-level controls.
The technical implementation of this vulnerability stems from the interaction between Git's path resolution and Windows network share access behaviors. When Git processes a commit containing a file that has been renamed, it attempts to resolve both the old and new file paths using realpath to maintain repository integrity. However, this resolution process does not adequately filter or restrict paths that resolve to network shares, allowing the system to attempt access to UNC paths such as \\server\share\path. The Windows operating system automatically handles these network path accesses by initiating NTLM authentication protocols, which systematically transmit authentication credentials and system identifiers to the network share. This process occurs without user intervention or awareness, making it particularly dangerous for untrusted commit histories. The vulnerability is classified as a path traversal issue that operates at the system call level rather than the application logic level, making it difficult to detect through traditional application security controls. This aligns with CWE-22 Path Traversal and CWE-200 Information Exposure vulnerabilities, as the flaw enables unauthorized information disclosure through improper path handling.
The operational impact of this vulnerability extends beyond simple information disclosure, potentially enabling attackers to harvest authentication credentials and system information that could be used for further exploitation. Attackers can craft malicious commits containing symbolic links or paths that resolve to network shares, tricking users into viewing these commits through GitHub Desktop's history view. Once accessed, the automatic network authentication triggers would expose the attacker to the user's computer name, username, and potentially NTLM hash values that could be used for credential replay attacks or pass-the-hash techniques. This vulnerability particularly affects Windows users who regularly browse commit histories from untrusted sources, as the attack requires only user interaction with a malicious commit rather than complex exploitation techniques. The security implications are significant because the vulnerability operates silently in the background during normal Git operations, with no visible warning to users about the information disclosure occurring. The attack scenario aligns with ATT&CK technique T1078 Valid Accounts, as it leverages legitimate user credentials and system access patterns to extract information, and T1566 Phishing, since the attack relies on social engineering to convince users to view malicious content.
The vulnerability was addressed in GitHub Desktop version 3.4.20 and later releases, with the beta channel incorporating the fix in 3.4.20-beta3. The solution involves enhanced path resolution logic that properly restricts access to network shares and prevents Git from attempting to resolve paths that would lead to network locations. Users unable to immediately upgrade should implement the recommended workaround of limiting history view browsing to commits from trusted sources only. This approach effectively mitigates the risk by preventing access to potentially malicious commit histories that could contain crafted paths designed to trigger the vulnerability. Additionally, system administrators should consider implementing network access controls to limit outbound connections to network shares from development environments, though this represents a secondary mitigation rather than a direct fix for the vulnerability. The fix demonstrates proper input validation and path resolution practices that prevent system-level path traversal attacks while maintaining the application's core functionality for legitimate repository browsing operations.