CVE-2024-32002 Git RCE on Clone: Walkthrough

Git CVE-2024-32002 is a CVSS 9.0 remote-code-execution vulnerability that the Git security team disclosed on May 14, 2024, alongside three related CVEs. The core issue is that on case-insensitive filesystems (Windows NTFS by default, macOS HFS+ and APFS by default), a malicious repository can cause git clone --recursive to write files into the .git directory of a submodule, including hook scripts that execute during the same clone operation. The practical effect is that merely cloning an attacker-controlled repository with --recursive gives the attacker code execution on the developer's workstation. Proof-of-concept exploits appeared within hours of disclosure, and several CI/CD platforms that performed automatic recursive clones had to issue emergency advisories.

What is the technical root cause of CVE-2024-32002?

The technical root cause of CVE-2024-32002 is that Git's submodule clone logic, when processing a repository that contains a submodule whose path collides with a symlink that resolves into a directory named .git/ on a case-insensitive filesystem, writes submodule content through the symlink into the parent's .git/modules/<name>/ directory. That directory is a real Git directory that Git will consult for hooks during the clone operation. A hooks/post-checkout file dropped through that write chain will be executed by the recursive clone before it finishes.

The attack requires a specific repository shape. The outer repository contains:

• A symbolic link named, for example, A pointing to .git/modules/x/hooks
• A submodule whose path is a (lowercase) and whose content includes an executable file named post-checkout

On a case-insensitive filesystem, A and a refer to the same path entry, so the symlink is resolved during submodule writeout and the submodule's post-checkout file lands in the hook directory. Git then invokes that hook during checkout, executing attacker-controlled code with the permissions of the cloning user.

The fix, shipped in Git 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, refuses to write through symlinks during submodule operations and validates path uniqueness with case-insensitivity awareness. Related CVEs (CVE-2024-32004, CVE-2024-32020, CVE-2024-32021) close adjacent classes of the same family of bugs.

Which Git versions and platforms are affected?

Affected versions are every Git release prior to the May 14, 2024 patches: 2.45.0 and earlier on the 2.45 series, 2.44.0 and earlier, and every previous minor line. Platforms where the bug is directly exploitable are those with case-insensitive filesystems, which means Windows (NTFS default), macOS (APFS and HFS+ default), and any Linux user who mounted an NTFS or exFAT volume and checked out into it. Pure Linux workstations using ext4, btrfs, or xfs are not affected by this specific CVE because those filesystems are case-sensitive, but they are affected by the related CVE-2024-32004 that does not require case-insensitivity.

Inventory surfaces that matter:

• Developer workstations (Windows and macOS by population)
• CI runners that clone untrusted repositories (most GitHub Actions, GitLab Runner, and Jenkins pipelines)
• Desktop IDEs that auto-clone via URL-handler schemes (VS Code, JetBrains IDEs, GitHub Desktop)
• Documentation systems that pull repositories on a schedule (Read the Docs, MkDocs CI pipelines)

GitHub Desktop and GitHub CLI each shipped updated Git binaries within a week of the advisory. JetBrains and Microsoft bundled updates into their regular product-update cycles, with some products lagging by a minor version.

How does the exploit reach RCE?

The exploit reaches RCE by relying on Git to run hook scripts automatically during the recursive clone operation. post-checkout is invoked by default at the end of every checkout, which happens once for the outer repository and once per submodule. By staging the hook file through the symlink-and-submodule trick, the attacker causes Git itself to invoke an attacker-controlled executable with the user's credentials.

Step-by-step as documented in public PoCs:

1. Attacker publishes a malicious outer repository, typically through a contribution to a larger project or a targeted social-engineering lure
2. Victim runs git clone --recursive <url> or opens the repository in an IDE that auto-runs a recursive clone
3. Git clones the outer repository and begins processing submodules
4. During submodule extraction, Git resolves the A symlink and writes the post-checkout file into .git/modules/x/hooks/post-checkout
5. Git completes the submodule checkout and triggers the post-checkout hook, executing the attacker's script
6. The script runs with the user's privileges before the clone command even returns

The exact trigger is reliable on Windows and macOS default filesystem configurations without any user interaction beyond initiating the recursive clone. Demo videos published by researchers Amit Laish and others show full shell access obtained within seconds of a developer clicking a GitHub URL in an IDE with clone-on-open behavior.

What IoCs did Git maintainers and researchers publish?

Public IoCs published by GitHub's security team, the Git project, and independent researchers include repository-shape patterns and post-clone host behaviors:

• Repositories whose .gitmodules file references a submodule whose path differs only by case from a symlink at the top level
• Commits that add both a symbolic link pointing inside .git/modules/ and a submodule reference, a combination that would ordinarily raise review flags
• Host-level creation of files under .git/modules/*/hooks/ outside of normal git init or explicit hook management
• Execution of post-checkout, post-merge, or post-update scripts within seconds of a git clone invocation, especially when the script path contains modules/
• IDE or shell child-process trees showing a script execution parented by the git process that recently returned from clone

CI runner logs are a particularly good detection surface because the full command and its output are usually preserved. A pipeline step that ran git clone --recursive and produced unexpected output from a hook script after the clone stage is a clear signal.

What are the exploitation preconditions?

The exploitation preconditions are straightforward and favor the attacker. The victim must clone a repository under the attacker's control with recursion enabled, and the target filesystem must be case-insensitive for CVE-2024-32002 specifically. Either precondition is typically met by default for Windows and macOS developers and for most package-build systems that pull dependencies through Git.

Factors that change the exploit window:

• IDE auto-clone features (VS Code's vscode://clone?url=... handler, JetBrains URL schemes): expand attacker-facing reach
• git config --global core.protectNTFS true (default on Windows since 2.22): mitigates specific path-traversal classes but does not fully close this CVE pre-patch
• Organizational allowlists of repository sources: narrow the attacker's reach to repositories hosted on approved servers
• git config --global protocol.file.allow user: the default since 2.38 already restricts the file:// transport

What the exploit does not require:

• No prior access to the victim's machine
• No credentials or tokens
• No binary payload inside the repository (the payload is a text script executed by Git)
• No ability to run arbitrary commands beyond submitting a Git URL

What is the patch and hardening plan?

The patch plan is to update Git to 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, or 2.39.4, depending on the maintained series, across every system that clones Git repositories. That includes developer workstations, CI runners, documentation builders, package managers that pull Git sources, and any embedded Git binaries inside vendor products. The Git project's advisory explicitly lists the seven patched release lines, and distributions shipped updates the same week.

Practical rollout sequence:

1. Update developer workstation Git binaries through managed software (Jamf, Intune, Chocolatey, Homebrew policies)
2. Update CI runner base images and rebuild all runner pools
3. Update vendor products that bundle Git: GitHub Desktop, GitKraken, Sourcetree, JetBrains IDEs, VS Code, Docker Desktop, and any developer-tooling installer the organization ships
4. Audit shared build infrastructure (Bazel remote execution, Buck2, Nix cache builders) for embedded Git versions
5. Audit container base images used by developer teams for embedded Git

Hardening that pays dividends beyond this CVE:

• Set git config --global core.symlinks false on Windows and macOS developer endpoints that do not need symlink materialization
• Use git -c core.hooksPath=/dev/null clone for clones of untrusted content in automation
• Move recursive clones of untrusted repositories into ephemeral sandboxes (container, VM)
• Disable IDE auto-clone URL handlers on managed endpoints

What are the supply chain implications?

The supply chain implications are broad because Git is the universal entry point into every software supply chain. An exploit that triggers on clone converts any "review this pull request" or "clone this example" workflow into a code-execution primitive. Three specific scenarios reported publicly after disclosure:

• CI runners that performed automatic recursive clones of pull-request branches from external contributors became RCE-by-default until patched
• Package managers that vendored dependencies via git clone --recursive (some Go modules in their older form, some Ruby bundler configurations) inherited the vulnerability
• Documentation-generation systems that pulled external repositories on a schedule were exploitable through a single malicious repository reference

GitHub Enterprise Server, GitLab self-managed, and Bitbucket Data Center each issued companion advisories covering bundled Git binaries on their platforms. Organizations running self-managed source-hosting platforms needed to patch both the platform and the developer endpoints to close the exposure end-to-end.

How Safeguard.sh Helps

Safeguard.sh inventories Git installations through 100-level dependency depth analysis that identifies every Git binary across workstations, CI runners, container base images, and vendor products that embed Git for clone and submodule operations. Reachability analysis cuts 60 to 80 percent of findings by confirming which installations actually perform recursive clones of untrusted content, so the patch queue reflects real attacker paths. Griffin AI autonomously drafts patch orchestration across Windows, macOS, and Linux fleets, identifies CI runner pools whose base images ship vulnerable Git, and proposes sandboxing configurations for automation that touches external repositories. Container self-healing rebuilds developer-tooling and CI runner images against patched Git versions without manual pipeline intervention, and SBOM generation and ingest captures the embedded Git binaries in vendor products that are easy to miss in manual inventories.