CVE-2024-32020: Git Privilege Escalation Vulnerability

CVE-2024-32020 Overview

CVE-2024-32020 is a Hard Link Attack vulnerability in Git, the widely-used revision control system. When performing local clones on the same disk, Git may create hardlinks to files in the source repository's object database. If the source repository is owned by a different user, those hardlinked files remain under the control of the potentially untrusted user and can be rewritten at any time, potentially compromising the integrity of the cloned repository.

Critical Impact
Untrusted users can modify hardlinked files in locally cloned repositories, allowing potential data manipulation or injection of malicious content into Git object databases.

Affected Products

Git versions prior to 2.45.1
Git versions prior to 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4
Fedora 40

Discovery Timeline

May 14, 2024 - CVE-2024-32020 published to NVD
January 6, 2026 - Last updated in NVD database

Technical Details for CVE-2024-32020

Vulnerability Analysis

This vulnerability stems from Git's optimization behavior during local clone operations. When cloning a repository located on the same disk, Git creates hardlinks to source files rather than copying them, which significantly speeds up cloning operations and saves disk space. However, this optimization introduces a security concern when the source repository is owned by a different user.

The hardlinked files continue to be owned and controlled by the original repository owner. If that user is untrusted or potentially malicious, they retain the ability to rewrite these files at will. This creates a scenario where an adversary could modify Git objects in repositories cloned from their controlled source, even after the clone operation completes.

Additionally, the cloning code was not prepared to handle edge cases where an adversary might racily swap out files for symlinks, potentially causing Git to inadvertently use the wrong source file during operations.

Root Cause

The root cause is classified as CWE-281 (Improper Preservation of Permissions). Git's local clone functionality did not verify repository ownership before creating hardlinks across user boundaries. The code path for local clones lacked ownership validation, allowing files from untrusted user-owned repositories to be hardlinked into the target repository without appropriate security checks.

Attack Vector

The attack requires local access to a shared filesystem where both the attacker and victim can access repositories. An attacker could:

Create a malicious repository on a shared disk
Wait for or social engineer a victim to clone the repository locally
After the clone, modify the hardlinked files in the source repository
Changes propagate to the victim's cloned repository through the shared hardlinks

The following security patch from builtin/clone.c demonstrates the fix that refuses cloning directories not owned by the current user:

 	struct dir_iterator *iter;
 	int iter_status;

+	/*
+	 * Refuse copying directories by default which aren't owned by us. The
+	 * code that performs either the copying or hardlinking is not prepared
+	 * to handle various edge cases where an adversary may for example
+	 * racily swap out files for symlinks. This can cause us to
+	 * inadvertently use the wrong source file.
+	 *
+	 * Furthermore, even if we were prepared to handle such races safely,
+	 * creating hardlinks across user boundaries is an inherently unsafe
+	 * operation as the hardlinked files can be rewritten at will by the
+	 * potentially-untrusted user. We thus refuse to do so by default.
+	 */
+	die_upon_dubious_ownership(NULL, NULL, src_repo);

 	mkdir_if_missing(dest->buf, 0777);

 	iter = dir_iterator_begin(src->buf, DIR_ITERATOR_PEDANTIC);

Source: Git Commit 1204e1a

Detection Methods for CVE-2024-32020

Indicators of Compromise

Local Git clones performed from repositories owned by different users on shared filesystems
Hardlinked files in .git/objects directories with unexpected ownership patterns
Unexplained modifications to Git object files after initial clone operations

Detection Strategies

Monitor local clone operations using git clone --local or clones on the same filesystem
Audit file ownership in .git/objects directories to identify hardlinks to untrusted sources
Implement file integrity monitoring for Git object databases in shared environments

Monitoring Recommendations

Track Git operations on multi-user systems with shared storage
Monitor for unexpected file permission or ownership changes in repository directories
Review Git configurations for safe.directory settings that may indicate workarounds for ownership issues

How to Mitigate CVE-2024-32020

Immediate Actions Required

Upgrade Git to patched versions: 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, or 2.39.4
Avoid local clones from repositories owned by untrusted users until patched
Re-clone any repositories that may have been locally cloned from untrusted sources

Patch Information

Security patches are available through the official Git repository. The fix adds ownership verification via the die_upon_dubious_ownership() function, which refuses to clone directories not owned by the current user. Key commits include:

Git Commit 1204e1a - Refuse local clones of unsafe repositories
Git Commit 9e65df5 - Merge branch with ownership checks

For Fedora users, updated packages are available through the Fedora Package Announcement.

Workarounds

Use the --no-local flag when cloning to force a proper clone instead of hardlinking
Add trusted source repositories to safe.directory configuration if they must be cloned locally
Ensure repositories are only cloned from trusted sources with verified ownership

bash

# Workaround: Force proper clone instead of hardlinking
git clone --no-local /path/to/source/repo target

# Alternative: Add trusted repository to safe.directory
git config --global --add safe.directory "/path/to/trusted/repo/.git"