Multiple security vulnerabilities have been disclosed in GitHub Desktop as well as other Git-related projects that, if successfully exploited, could permit an attacker to gain unauthorized access to a user’s Git credentials.
“Git implements a protocol called Git Credential Protocol to retrieve credentials from the credential helper,” GMO Flatt Security researcher Ry0taK, who discovered the flaws, said in an analysis published Sunday. “Because of improper handling of messages, many projects were vulnerable to credential leakage in various ways.”
The list of identified vulnerabilities is as follows –
- CVE-2025-23040 (CVSS score: 6.6) – Maliciously crafted remote URLs could lead to credential leaks in GitHub Desktop
- CVE-2024-50338 (CVSS score: 7.4) – Carriage-return character in remote URL allows the malicious repository to leak credentials in Git Credential Manager
- CVE-2024-53263 (CVSS score: 8.5) – Git LFS permits retrieval of credentials via crafted HTTP URLs
- CVE-2024-53858 (CVSS score: 6.5) – Recursive repository cloning in GitHub CLI can leak authentication tokens to non-GitHub submodule hosts
While the credential helper is designed to return a message containing the credentials that are separated by the newline control character (“n”), the research found that GitHub Desktop is susceptible to a case of carriage return (“r”) smuggling whereby injecting the character into a crafted URL can leak the credentials to an attacker-controlled host.
“Using a maliciously crafted URL it’s possible to cause the credential request coming from Git to be misinterpreted by Github Desktop such that it will send credentials for a different host than the host that Git is currently communicating with thereby allowing for secret exfiltration,” GitHub said in an advisory.
A similar weakness has also been identified in the Git Credential Manager NuGet package, allowing for credentials to be exposed to an unrelated host. Git LFS, likewise, has been found not to check for any embedded control characters, resulting in a carriage return line feed (CRLF) injection via crafted HTTP URLs.
On the other hand, the vulnerability impacting GitHub CLI takes advantage of the fact that the access token is configured to be sent to hosts other than github[.]com and ghe[.]com as long as the environment variables GITHUB_ENTERPRISE_TOKEN, GH_ENTERPRISE_TOKEN, and GITHUB_TOKEN are set, and CODESPACES is set to “true” in the case of the latter.
“While both enterprise-related variables are not common, the CODESPACES environment variable is always set to true when running on GitHub Codespaces,” Ry0taK said. “So, cloning a malicious repository on GitHub Codespaces using GitHub CLI will always leak the access token to the attacker’s hosts.”
Successful exploitation of the aforementioned flaws could lead to a malicious third-party using the leaked authentication tokens to access privileged resources.
In response to the disclosures, the credential leakage stemming from carriage return smuggling has been treated by the Git project as a standalone vulnerability (CVE-2024-52006, CVSS score: 2.1) and addressed in version v2.48.1.
“This vulnerability is related to CVE-2020-5260, but relies on behavior where single carriage return characters are interpreted by some credential helper implementations as newlines,” GitHub software engineer Taylor Blau said in a post about CVE-2024-52006.
The latest version also patches CVE-2024-50349 (CVSS score: 2.1), which could be exploited by an adversary to craft URLs containing escape sequences to trick users into providing their credentials to arbitrary sites.
Users are advised to update to the latest version to protect against these vulnerabilities. If immediate patching is not an option, the risk associated with the flaws can be mitigated by avoiding running git clone with –recurse-submodules against untrusted repositories. It’s also recommended to not use the credential helper by only cloning publicly available repositories.
