Executive Summary:

During testing, the host was running Git version 2.45.2, which lies within the vulnerable range (with fixes starting from version 2.45.4). To demonstrate the issue, a custom proof-of-concept repository was created under my GitHub account and cloned using the --recursive option — the trigger condition for this vulnerability.

After the clone operation completed, a malicious post-checkout hook was executed, which created a file in the /tmp directory (/tmp/payload.log) containing the message “Hello from payload!”. This validated that the exploit successfully achieved arbitrary file write and code execution outside the repository directory.

Although this PoC used a benign payload, the same technique could be weaponized by an attacker to implant malicious Git hooks or tamper with configuration files, potentially enabling persistent remote code execution (RCE) during future Git operations.

Affected Version:

CVE-2025-48384 impacts Git CLI installations on Linux and macOS when using git clone --recursive. The vulnerability exists in the following versions:

• 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 all prior releases

Systems running any of these versions on Linux or macOS are vulnerable.
Windows systems are not affected due to differences in handling carriage return (\r) characters.

Additionally, the GitHub Desktop client for macOS is vulnerable because it invokes git clone --recursive by default and, at the time of disclosure, did not include the patched Git versions.

The vulnerability has been patched in the following fixed releases:

• 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

Vulnerability Details:

Root Cause:

CVE-2025-48384 exists due to how Git parses and writes configuration values from the .gitmodules file when cloning repositories with submodules using the --recursive flag. The vulnerability stems from a mismatch in Git’s handling of control characters, particularly carriage returns (\r). If a submodule path ends with a carriage return:

• When reading the configuration, Git strips the trailing carriage return.
• When writing the configuration back to disk, Git preserves the carriage return.

This discrepancy enables an attacker to manipulate submodule paths in a way that causes Git to write files outside the intended repository directory.
In my custom proof-of-concept, this behavior was weaponized to create /tmp/payload.log containing the message "Hello from payload!" during the cloning process. This demonstrates that arbitrary file writes and code execution can be achieved using a controlled malicious repository.

By leveraging this primitive, an attacker could escalate the impact further, for example:

• Writing malicious Git hook scripts into .git/hooks/, leading to automatic remote code execution (RCE) when the victim runs commands like git commit or git merge.
• Overwriting .git/config to redirect remotes or silently exfiltrate source code, enabling persistence and stealthy data theft.

Windows systems remain unaffected because carriage return (\r) characters are handled differently in file paths.

Exploitation Flow:

Exposure & Risk

Impact: Arbitrary File Write leading to Remote Code Execution (RCE), Data Exfiltration, and Persistence.

Stealth Factor: The exploit is triggered through a normal git clone --recursive workflow. The payload can be hidden within .gitmodules and executed automatically via Git hooks, blending seamlessly into standard developer activity.

Attack Scenarios:

• Malicious Open-Source Repositories: Attackers host weaponized projects with recursive submodules, tricking developers into cloning them.
• Supply Chain Attacks: Poisoned repositories introduced into CI/CD pipelines leveraging recursive clones.
• Insider Threats: Internal repositories modified to plant backdoor hooks silently.
• Developer Workstation Takeover: Exploiting GitHub Desktop for macOS (vulnerable by default) during ordinary clone operations.

 

Risk Level:

High (CVSS 8.1/10) — Successful exploitation allows arbitrary code execution and potential source code exfiltration, posing a significant risk to developer environments and software supply chains.

Proof-of-Concept and Active Exploitation:

Exploitation of CVE-2025-48384 is straightforward for an attacker but difficult for a victim to detect in real time. The vulnerability arises when a user performs a recursive clone operation (git clone --recursive) on an untrusted repository containing a malicious .gitmodules file. Within this file, the attacker appends carriage return (\r) characters to submodule paths. While Git’s parser strips these characters when reading configuration values, it preserves them when writing back to disk. This inconsistency enables the attacker to manipulate how submodule paths are resolved, redirecting Git’s write operations to unintended filesystem locations. The result is a reliable arbitrary file write primitive that can be escalated into more impactful attack vectors.

In custom exploitation test, hosted a malicious repository on GitHub and performed a recursive clone on a vulnerable Git version (2.45.2). During the cloning process, Git attempted to resolve and initialize submodules, but due to the poisoned paths, a malicious post-checkout hook executed. As a result, a file was created at /tmp/payload.log containing the message:

Hello from payload!

This demonstrates that arbitrary file writes and code execution can be achieved during a simple clone operation.

Once arbitrary files are achieved, attackers can escalate their access in multiple ways. One common technique involves writing a malicious Git hook script into the .git/hooks/ directory of the victim’s repository. Hooks such as pre-commit or post-merge are automatically executed whenever certain Git operations are performed, providing a path to arbitrary code execution. In practice, this transforms the file-write primitive into full remote code execution (RCE), executed under the security context of the victim’s user account.

Another powerful exploitation path is Git configuration hijacking. By overwriting the .git/config file, the attacker could silently redirect repository operations. For example, the [remote “origin”] section could be modified to point to an attacker-controlled server. In this way, source code commits, pull requests, or updates would automatically exfiltrate sensitive intellectual property or proprietary application code without the victim’s awareness. Because Git operations would continue to function normally, the compromise remains invisible to casual inspection. This persistence not only undermines developer environments but also places entire organizations at risk of intellectual property theft and source code leakage.

Beyond developer workstations, this vulnerability also has serious supply chain implications. Many CI/CD build systems automatically perform recursive clones when pulling project dependencies. If a poisoned repository is introduced into the build pipeline, it can result in arbitrary file writes within the build environment. This could compromise build artifacts, inject malicious code into software releases, or modify system files critical to pipeline integrity. With the increasing reliance on automation in modern DevOps workflows, exploitation can cascade far beyond the initial developer, ultimately impacting downstream consumers of affected software.

The exploitation scenarios for CVE-2025-48384 highlight both the stealth and severity of the vulnerability. On the surface, the attacker merely convinces a victim to run a common Git command—often recommended as best practice by legitimate projects. In my reproduction, the outcome was the creation of /tmp/payload.log, but a real-world attacker could escalate this into remote code execution, persistence on developer endpoints, or silent data exfiltration in CI/CD environments. Combined with the ease of delivery through phishing, trojanized repositories, or compromised open-source dependencies, this vulnerability poses a substantial risk to organizations relying on Git for version control.

Mitigation

To address CVE-2025-48384, organizations should immediately upgrade Git to the latest patched release (≥ 2.45.3 or the version recommended by the vendor). Using older or unpatched versions exposes systems to potential exploitation. In addition, the following security measures are recommended:

• Apply Vendor Patch: Upgrade Git to a secure version released after the vulnerability disclosure.
• Restrict External Repositories: Prevent cloning of untrusted or unknown Git repositories, especially in production environments.
• Implement File System Monitoring: Monitor system directories (e.g., /tmp) for unexpected files or artifacts created during repository interactions.
• Endpoint Security Controls: Enable EDR (Endpoint Detection & Response) solutions to detect unusual file execution attempts and abnormal repository behaviors.
• Security Awareness: Train developers and system administrators not to use vulnerable versions and avoid running PoCs or unverified Git repositories on production systems.

Timeline

Conclusion

The discovery of CVE-2025-48384 underscores how even essential and widely relied upon developer tools like Git can become significant attack vectors when flaws emerge. Repository-based vulnerabilities not only compromise system integrity but can also be leveraged for malicious file manipulation, malware delivery, and potential privilege escalation. Developers and organizations must respond quickly—by applying the official patches, avoiding the use of vulnerable versions, and carefully vetting external repositories before integration.

Strengthening security through endpoint monitoring, supply chain risk management, and continuous vulnerability scanning is critical to detect abnormal repository behaviors before exploitation occurs. Leveraging early threat intelligence, coordinated advisories, and proactive patch management helps reduce exposure. In today’s evolving threat landscape, maintaining vigilance and implementing layered security controls are essential to safeguard against exploitation of trusted tools like Git.

 

---

 

At CyberXTron, we specialize in Autonomous Digital Risk Protection and AI-driven Threat Intelligence tailored for protection against hacktivist threats and targeted cyber-attacks. 

Click  here to Book a free consultation with our expert team!!!