Full Report
Git implements a helper protocol called Git Credential Protocol to retrieve credentials from a process. There are several implementations of this depending on the platform, such as Windows and MacOS. The Git Credential Protocol separates parameters using newlines (\n). For instance, sending protocol=https\nhost=github.com\n would return protocol=https\nhost=github.com\nusername=USERNAME\npassword=PASSWORD. Git forbids newline and NULL byte characters in any of these names. But, is this sufficient? GitHub Desktop has a feature where a user can supply credentials to a Git client automatically. The code uses a regular expression in multiline mode to parse a URL passed in. Since \r is a splitter for regex and is allowed by the protocol, this creates a problem. The same attack could be launched on the .NET version of this product as well. A malicious repository with a crafted submodule URL can cause a git credential leak by adding more information to the request than anticipated via including carriage returns - http://%0dprotocol=https%0dhost=github.com%0d@localhost:13337/. This will break into the following: protocol=http host=localhost username=\rprotocol=https\rhost=github.com\r git LFS is an extension of git for large files. Although core git rejects newlines, they are not rejected by LFS. Using the configuration file .lfsconfig, newline injection into the protocol is possible - this issue required an alternative path to hit. url = http://%0Ahost=github.com%0Aprotocol=https%0A@localhost:13337/ would turn into the following: capability[]=authtype capability[]=state protocol=http host=localhost username= host=github.com protocol=https The next two are simple access control bugs IMO. The GitHub CLI will leak the access token to arbitrary hosts that are making requests. The tokenForHost function will always return true for non-GitHub owned instances. There are several cases where this is sent, such as GitHub enterprises, and CodeSpaces environment variables are set. The credential helper on GitHub Codespaces was a very simple bash script that always returns the token to Git. Although the host parameter is set to github.com, this isn't actually validated by git to match the currently requested host. So, Codespaces will send the token to the domain that hosts the repos, even if not GitHub.com. Overall, a good series of vulnerabilities with string parsing complexities. Great research!
Analysis Summary
# Vulnerability: Git Credential Protocol Bypasses Leading to Credentials Leakage
## CVE Details
- CVE ID: Multiple (CVE-2025-23040, CVE-2024-50338, CVE-2024-53263, CVE-2024-52006, CVE-2024-53858)
- CVSS Score: Not explicitly provided, severity inferred as High due to credential leakage.
- CWE: CWE-706 (Use of Incorrectly Resolved Name or Reference), CWE-20 (Improper Input Validation)
## Affected Systems
- Products: GitHub Desktop, Git Credential Manager (.NET implementation), Git LFS, GitHub CLI, Git credential helper on GitHub Codespaces.
- Versions: Not explicitly listed, but affects versions implementing the vulnerable parsing logic prior to patches.
- Configurations: Any system utilizing the affected credential helpers or clients where malicious repositories can be cloned/used.
## Vulnerability Description
A series of vulnerabilities stem from improper handling and validation of input within the Git Credential Protocol parsing across various Git ecosystem components. The protocol uses newlines (`\n`) as delimiters, but other characters, notably the carriage return (`\r`), are sometimes permitted by specific parsers (e.g., regular expressions in multiline mode) or are not rejected by extensions (like Git LFS).
1. **GitHub Desktop (CVE-2025-23040):** Uses a regular expression in multiline mode to parse URLs for credential retrieval. Since carriage return (`\r`) acts as a delimiter for the regex engine and is allowed by the protocol spec in certain contexts, an attacker can inject crafted submodule URLs containing `\r` to smuggle extra parameters, leading to credential leakage (`protocol=https\rhost=github.com\rusername=...`).
2. **Git Credential Manager (.NET):** Improper usage of `StreamReader` also allowed carriage return smuggling.
3. **Git LFS (CVE-2024-53263):** Core Git rejects newlines, but Git LFS did not reject them in its configuration (`.lfsconfig`), enabling newline injection into the protocol to break out of expected parameter structure and leak credentials.
4. **GitHub CLI (CVE-2024-53858):** The `tokenForHost` function incorrectly returns true for any non-GitHub owned instance (e.g., GitHub Enterprises, Codespaces environments), causing the access token to be leaked to arbitrary hosts making credential requests.
5. **GitHub Codespaces Credential Helper:** A simple bash script credential helper did not validate the requested host against `github.com`. Thus, the token was sent to the domain hosting the repository, even if it was not GitHub.com.
## Exploitation
- Status: PoC available (demonstrated via crafted repository URLs).
- Complexity: Low to Medium, depending on the target component (e.g., crafting malicious submodule URLs vs. host validation bypass).
- Attack Vector: Network (via malicious repository/submodule URL).
## Impact
- Confidentiality: High (Leakage of usernames, passwords, and GitHub Access Tokens).
- Integrity: Low (No direct elevation of privilege implied, but token leakage can lead to integrity compromise on connected services).
- Availability: Low
## Remediation
### Patches
Specific CVE patches should be applied to the respective products:
* **CVE-2025-23040 (GitHub Desktop):** Patch to correctly handle or reject carriage returns in URL parsing within the credential helper logic.
* **CVE-2024-50338 (GCM .NET):** Patch to fix improper input handling in `StreamReader`.
* **CVE-2024-53263 (Git LFS):** Patch to enforce newline rejection where necessary, especially in configuration pathways affecting credential interaction.
* **CVE-2024-53858 (GitHub CLI):** Patch to strictly validate the target host before exposing tokens via the `tokenForHost` function.
* **Codespaces Helper:** Patch to implement strict host validation (e.g., ensuring `$url = $GITHUB_SERVER_URL`).
### Workarounds
1. **General:** Avoid cloning repositories from untrusted sources until patches are applied.
2. **Custom Helper Scripts:** If using custom `credential.helper` scripts, ensure they explicitly validate the requested host parameter against the expected server URL before outputting credentials.
3. **Per-Host Configuration:** Configure credential helpers on a per-host basis (e.g., `credential.https://github.com.helper=...`) to limit the scope of the helper execution if possible.
## Detection
- **Indicators of Compromise:** Outbound network connections from the local machine or Codespaces environment to unexpected external hosts originating from Git processes utilizing credentials.
- **Detection Methods and Tools:** Monitor process execution of credential helpers (`trampoline-credential-helper.ts` related processes, GCM, or custom scripts) that interact with non-standard or untrusted domains, especially for requests containing token data.
## References
- Vendor advisories (Referencing individual vendor security bulletins for specific patch details).
- Original Research: hXXps://flatt.tech/en/research/posts/clone2leak-your-git-credentials-belong-to-us