Update - July 11, 2025:
We are making a correction to the Git CLI versions vulnerable to this based on updates to the GitHub advisory around affected versions.
Key points and observations
- CVE-2025-48384 is a vulnerability that allows arbitrary file write, and ultimately code execution, on Linux and macOS when using
git clone --recursiveon a weaponized repository. - The vulnerability can be exploited to write a malicious Git Hook script, resulting in remote code execution (RCE) whenever subcommands like
git commitandgit mergeare run. - On July 8, 2025, Git did a coordinated release of new versions of git to address this vulnerability. Any Git client not running one of the following patched versions should be considered vulnerable: v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1.
- The GitHub Desktop client for macOS is also vulnerable, due to its use of
git clone --recursiveby default. - The vulnerability has been assigned a CVSS severity score of High (8.1/10).
- Working proof-of-concept exploits for this vulnerability are publicly available and have been validated by Datadog security researchers.
How to know if you are vulnerable
- For hosts running Git CLI on macOS and Linux, issue the command git --version and check to see if the returned version is not on v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, or v2.50.1
- At the time of writing, there is no known patch available for the GitHub Desktop client, according to the changelog. If you are currently using the GitHub Desktop client on macOS, you should assume you’re vulnerable until GitHub releases a patch. If you need to perform Git clone operations, we recommend using a patched version of the Git CLI instead.
Vulnerability details
CVE-2025-48384 is a newly discovered vulnerability that enables arbitrary file write when cloning untrusted repositories with submodules using the --recursive flag on UNIX-like systems. The flaw arises from Git’s handling of configuration values and carriage return (\r, or CR) characters when parsing the .gitmodules file, allowing attackers to manipulate the internal submodule paths and cause Git to write files to unexpected locations.
This vulnerability stems from a mismatch in how Git reads versus writes configuration values containing control characters. An attacker can craft a malicious .gitmodules file with submodule paths ending in a carriage return. Due to Git’s config parser behavior, this character may be stripped on read but preserved on write, allowing malicious redirection of submodule contents. When combined with symlinks or certain repository layouts, this can lead to arbitrary writes across the filesystem.
Git CLI installations prior to the patched versions of v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1 on macOS and Linux are affected, while Windows is not, due to differences in control character usage in systems not derived from UNIX. The macOS GitHub Desktop client is also affected because it recursively clones repositories by default, essentially issuing git clone --recursive under the hood. This will largely affect software developers using Git on workstations to version control their code, but we have also identified usage of vulnerable Git versions in customer CI/CD build systems.
How the vulnerability can be exploited
Since running git clone --recursive is frequently encouraged in READMEs for open source projects, an attacker could publish a weaponized repository with this instruction and use it to achieve an arbitrary file write on a victim endpoint.
A likely exploitation scenario would be to abuse the arbitrary write primitive to write out a malicious Git Hook script, contained in the attacker repository’s submodule, to the user’s .git subdirectory. This malicious payload would then be executed whenever common Git operations, such as committing and merging, are performed.
An attacker could also abuse the vulnerability to overwrite the victim’s Git configuration file. This could be used to exfiltrate intellectual property (such as proprietary source code) to an attacker’s server, via malicious modification of the [remote “origin”] section of the config file. Such Git activities would be transparent to the victim, allowing stealthy persistence for the attacker.
How to remediate affected machines
- If you discover that v2.50.0, v2.49.0, v2.48.0-v2.48.1, v2.47.0–v2.47.2, v2.46.0–v2.46.3, v2.45.0-v2.45.3, v2.44.0–v2.44.3, v2.43.6 and prior of Git CLI are installed on your hosts, upgrade to v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1 or above using your package manager of choice.
- Users of the GitHub Desktop client on macOS should avoid using the client for Git operations and instead opt to use the Git CLI until a patch is released. Additionally, when cloning repositories from untrusted sources, we highly recommend auditing the contents of submodules in the .gitmodules file before cloning.
How Datadog can help
- Workload Protection customers can run this query to check existing Workload Protection events for CLI usage of the
--recursiveoption. Review the commands for external or suspicious repositories.
- Workload Protection customers can also deploy this expression as a custom Agent rule to detect potential exploitation. This rule may need to be tuned to exclude legitimate hooks or repositories:
exec.comm in ["dash","sh","static-sh","sh","bash","bash","bash-static","zsh","ash","csh","ksh","tcsh", \
"busybox","busybox","fish","ksh93","rksh","rksh93","lksh","mksh","mksh-static","csharp","posh","rc", \
"sash","yash","zsh5","zsh5-static"] && process.ancestors.comm == "git" \
&& process.ancestors.argv in ["clone"] && process.ancestors.args_flags in ["recursive"]
- Cloud Security Vulnerabilities customers can run this query to list all running hosts, host images, and container images in their infrastructure with a vulnerable versions of the Git CLI installed:
