CVE-2024-32021 Overview
CVE-2024-32021 is a Time-of-Check Time-of-Use (TOCTOU) race condition vulnerability in Git, the widely-used distributed version control system. When cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the objects/ directory. This vulnerability allows an attacker to bypass existing symlink protections that were introduced to address CVE-2022-39253, potentially exposing sensitive user data through malicious repository operations.
Critical Impact
An attacker with local access can exploit this race condition to create hardlinks to arbitrary user-owned files, potentially exposing sensitive data such as SSH keys, credentials, or configuration files to unauthorized access.
Affected Products
- Git versions prior to 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4
- Fedora 40
- Debian Linux 10.0 and 11.0
Discovery Timeline
- May 14, 2024 - CVE-2024-32021 published to NVD
- January 5, 2026 - Last updated in NVD database
Technical Details for CVE-2024-32021
Vulnerability Analysis
This vulnerability represents a classic TOCTOU race condition in Git's local clone optimization logic. When cloning a repository over the filesystem without explicitly specifying the file:// protocol or using the --no-local flag, Git employs performance optimizations that attempt to hardlink object files instead of copying them. While the Git codebase includes checks against symbolic links in the source repository—protections that were added during the fix for CVE-2022-39253—these checks can be raced because the hardlink operation ultimately follows symlinks.
The exploitation window exists between the security check and the actual hardlink operation. If an attacker can manipulate the filesystem state such that an object appears as a regular file during the check but becomes a symlink before the hardlink operation completes, the attacker successfully bypasses the protection mechanism. This allows the creation of hardlinks in the destination repository's objects/ directory pointing to arbitrary user-readable files on the same filesystem.
Root Cause
The root cause of CVE-2024-32021 lies in the non-atomic nature of the check-and-link sequence in Git's local clone functionality. The security check for symlinks and the subsequent hardlink operation are separate filesystem operations, creating a window during which the file type can be changed. This TOCTOU vulnerability occurs because:
- Git checks if the source object is a regular file (not a symlink)
- Between this check and the hardlink creation, an attacker can replace the file with a symlink
- The hardlink operation follows the symlink, linking to the attacker-specified target file
Attack Vector
The attack requires local access and involves a malicious source repository that the victim clones. The attacker prepares a repository containing objects that can be swapped between regular files and symlinks during the clone operation. The attack flow typically involves:
- Attacker creates a malicious local repository with specially crafted objects
- The attacker runs a concurrent process that rapidly alternates object files between regular files and symlinks pointing to sensitive target files (such as ~/.ssh/id_rsa)
- When the victim clones this repository using local filesystem optimizations, the race condition may be won
- If successful, the victim's cloned repository contains hardlinks to the attacker-specified sensitive files
- These hardlinks can then be accessed through the cloned repository's objects/ directory
The attack is constrained to the local filesystem, requiring both the malicious source repository and target sensitive files to reside on the same filesystem. The attacker needs to win the race condition, which may require multiple attempts depending on system timing characteristics.
Detection Methods for CVE-2024-32021
Indicators of Compromise
- Unexpected hardlinks in the objects/ directory of newly cloned repositories pointing to files outside the repository structure
- Abnormal file system activity during clone operations, particularly rapid file type changes
- Cloned repositories with objects that resolve to sensitive system or user files such as SSH keys, credentials, or configuration files
- Unusual permission warnings or errors when accessing cloned repository objects
Detection Strategies
- Monitor for rapid file type changes (file to symlink) in repository directories during clone operations
- Implement file integrity monitoring on sensitive files to detect unexpected hardlink creation
- Use audit logging to track clone operations with local repositories and correlate with filesystem metadata changes
- Deploy endpoint detection rules that alert on unusual hardlink creation patterns in user directories
Monitoring Recommendations
- Enable Git audit logging to track repository operations and flag local clones without explicit file:// protocol usage
- Configure filesystem auditing to monitor the objects/ directory of new repository clones for external hardlinks
- Implement SentinelOne behavioral AI to detect suspicious process activities involving concurrent file type manipulation and Git operations
- Review clone operations from untrusted sources and quarantine repositories pending security validation
How to Mitigate CVE-2024-32021
Immediate Actions Required
- Update Git to the latest patched version: 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, or 2.39.4 depending on your version branch
- Avoid cloning untrusted local repositories until patches are applied
- Use the --no-local flag or explicit file:// protocol when cloning local repositories from untrusted sources to disable local optimizations
- Audit recently cloned repositories for suspicious hardlinks in the objects/ directory
Patch Information
Git has released security patches addressing this vulnerability across multiple supported version branches. Users should update to the following fixed versions:
| Version Branch | Patched Version |
|---|---|
| 2.45.x | 2.45.1 |
| 2.44.x | 2.44.1 |
| 2.43.x | 2.43.4 |
| 2.42.x | 2.42.2 |
| 2.41.x | 2.41.1 |
| 2.40.x | 2.40.2 |
| 2.39.x | 2.39.4 |
For detailed information, see the GitHub Security Advisory GHSA-mvxm-9j2h-qjx7. Distribution-specific patches are available through Fedora Package Announcement and Debian LTS Announcement.
Workarounds
- Use explicit file:// protocol when cloning local repositories to bypass local optimizations that enable this attack
- Add the --no-local flag to clone commands when working with local repositories from untrusted sources
- Configure Git to disable local clone optimizations globally by setting protocol.file.allow to user or never
- Clone from remote URLs instead of local paths when the repository origin is not fully trusted
# Configuration example
# Disable local clone optimizations by forcing file:// protocol behavior
git config --global protocol.file.allow user
# Clone with explicit --no-local flag to prevent hardlink optimization
git clone --no-local /path/to/untrusted/repository destination
# Alternative: Use explicit file:// protocol
git clone file:///path/to/untrusted/repository destination
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

