Git Clone RCE via Symlink Race on Case-Insensitive Filesy...

In March 2021, the Git project shipped a coordinated set of security releases to fix CVE-2021-21300, a vulnerability that allowed a malicious repository to achieve remote code execution on a victim's machine simply by being cloned. The flaw combined a symlink attack with a filesystem race condition on case-insensitive filesystems — the default configuration on macOS and Windows — turning an everyday git clone into a potential clone RCE. For a software supply chain that runs on trust in source repositories, CVE-2021-21300 is a textbook example of how a single edge case in filesystem semantics can undermine that trust entirely.

What Is CVE-2021-21300?

Git normally treats the working tree and the .git directory as strictly separate. Git's checkout logic includes protections designed to prevent a repository from writing files into .git itself — for example, blocking a tracked path literally named .git on disk. But those protections were built assuming a case-sensitive filesystem, where .git and a path like .GIT or .Git are different names.

On a case-insensitive filesystem — which includes the default HFS+/APFS configuration on macOS and NTFS on Windows — those two paths collide. CVE-2021-21300 exploited this by crafting a repository containing a specially cased directory (case-mangled to look like .git) alongside content that Git's clean/smudge filter mechanism (the same machinery used by Git LFS and similar filters) processes asynchronously as part of a "delayed checkout."

Delayed checkout writes files to disk in a separate step after the initial checkout pass, and it does so through the filesystem rather than atomically. That gap between when Git decides what to write and when it actually writes it is the race window. An attacker structured the repository so that, during that window, a symlink could be substituted in place of a regular file, redirecting a subsequent write into the real .git directory — for instance, into .git/hooks/. Because Git hooks are executable scripts that run automatically (a post-checkout hook fires right after cloning completes), planting one this way meant the attacker's code executed the moment the victim finished cloning the repository, with no further interaction required beyond running git clone --recurse-submodules (or an equivalent) against the malicious repo.

In short: a case-insensitive filesystem race condition let a hostile repository smuggle a symlink attack past Git's own directory-traversal defenses, converting a routine clone operation into arbitrary code execution.

Affected Versions and Components

CVE-2021-21300 affected all Git versions prior to the fixes issued in the March 9, 2021 security release. Because the underlying checkout and filter-writing code is shared across the entire Git codebase, the vulnerability was not limited to one platform's Git distribution — it affected upstream Git core wherever it ran on a case-insensitive filesystem with symlink support enabled, most notably:

• macOS, where the default APFS/HFS+ volume format is case-insensitive.
• Windows, via Git for Windows and other NTFS-based setups, particularly when core.symlinks was enabled.
• Any Linux setup using a case-insensitive overlay or filesystem mode, though this is far less common.

Exploitation additionally required the victim's clone operation to trigger the delayed-checkout path, which in practice meant repositories relying on a clean/smudge filter driver such as Git LFS, along with recursive submodule handling. That precondition narrowed real-world exposure somewhat, but the underlying components — Git's core checkout engine and its filter protocol — are used broadly enough that the vulnerability was treated as a critical, upstream-wide issue rather than a niche edge case. Git-based tooling that bundled its own vendored Git binary (desktop GUI clients, IDE integrations, CI runner images) also needed to update independently rather than relying on an OS-level patch.

The fix landed in Git 2.30.2, with matching backports released simultaneously across every actively maintained line at the time, including 2.29.3, 2.28.1, 2.27.1, 2.26.3, 2.25.5, 2.24.4, 2.23.4, 2.22.5, 2.21.4, 2.20.5, 2.19.6, 2.18.5, and 2.17.6 — a reflection of how seriously the maintainers treated a bug reachable by simply cloning a repository.

Severity: CVSS, EPSS, and KEV Context

NVD's entry for CVE-2021-21300 rates it in the High severity range under CVSS v3.1, reflecting a network-exploitable vector that requires some user interaction (initiating a clone) but no authentication and no prior access to the target system — consistent with an attacker needing only to convince a victim to clone or pull from a repository they control or have compromised. Given that the outcome is full code execution in the context of the cloning user, the practical severity is on par with other critical client-side RCE bugs, even where the numeric score sits a notch below a perfect 10 due to the specific preconditions (delayed checkout via a filter driver, case-insensitive filesystem) needed to trigger it.

CVE-2021-21300 has not appeared in CISA's Known Exploited Vulnerabilities (KEV) catalog, and public EPSS scoring has consistently placed it at the lower end of the exploitation-probability spectrum. That's typical for vulnerabilities requiring a fairly specific setup rather than a universally reachable code path — there's no indication of widespread active exploitation, but the technique remains fully viable against any unpatched Git client that meets the preconditions, and proof-of-concept detail is public.

Timeline

• Prior to March 2021 — The vulnerability exists silently in Git's checkout and delayed-checkout/filter-driver logic across all supported release lines.
• March 9, 2021 — The Git project publicly discloses CVE-2021-21300 and simultaneously ships Git 2.30.2 along with backported fixes across thirteen release branches, patching the flaw in one coordinated release.
• March 2021 (following days/weeks) — Downstream distributors — Git for Windows, GitHub Desktop, GitLab, package managers, and Linux distribution maintainers — pull in the upstream fix and push updated builds to users.
• Ongoing — CVE-2021-21300 is tracked in NVD and GitHub Advisory Database (GHSA-8p95-cqmr-5v2q) as a reference point for filesystem-dependent supply chain risks in version control tooling; it continues to be cited in Git security hardening guidance.

Remediation Steps

1. Upgrade Git immediately. Update to Git 2.30.2 or later, or the corresponding patched release on your maintenance branch (2.29.3, 2.28.1, 2.27.1, 2.26.3, 2.25.5, 2.24.4, 2.23.4, 2.22.5, 2.21.4, 2.20.5, 2.19.6, 2.18.5, 2.17.6, or newer). This applies to every machine that clones repositories — developer laptops, CI/CD runners, build servers, and container images with Git baked in.
2. Patch bundled Git clients separately. Git for Windows, GitHub Desktop, SourceTree, JetBrains IDEs, and any tool that vendors its own Git binary needs an independent update; an OS patch alone won't fix a bundled, out-of-date copy.
3. Avoid cloning untrusted repositories with --recurse-submodules or LFS filters enabled until your Git version is confirmed patched, since that combination is what triggers the vulnerable delayed-checkout path.
4. Harden filesystem defaults where feasible. Disabling core.symlinks in environments that don't need symlink support removes one leg of the exploit chain, though upgrading Git remains the authoritative fix.
5. Audit CI/CD images and golden AMIs/containers. Pinned base images often freeze a Git version at build time; confirm your pipeline images were rebuilt after March 2021 and haven't silently drifted back to a vulnerable version through caching.
6. Inventory your fleet. Confirm every developer workstation, build agent, and automation identity that runs git clone, git pull, or git submodule update is on a patched version — this is a client-side vulnerability, so server-side hosting patches (GitHub.com, GitLab.com) don't protect a developer running vulnerable local Git.

How Safeguard Helps

CVE-2021-21300 is a reminder that software supply chain risk doesn't stop at the code you write — it includes the tools your teams use to fetch that code in the first place. Safeguard is built to close exactly this kind of blind spot:

• Toolchain and dependency version visibility. Safeguard continuously inventories the Git and VCS tooling versions in use across developer machines, CI runners, and build environments, flagging any instance still running a version affected by CVE-2021-21300 or similar clone-time vulnerabilities.
• CI/CD pipeline policy enforcement. Safeguard can gate pipeline runs on minimum tool versions, preventing a stale, vulnerable Git binary baked into a cached container image from silently reintroducing risk after a fleet-wide upgrade.
• Untrusted repository and submodule risk detection. Because this class of clone RCE hinges on submodule handling and filter-driven delayed checkout, Safeguard's supply chain monitoring flags risky clone patterns — such as recursive submodule fetches from unverified sources — as part of its broader software composition analysis.
• SBOM and build-environment attestation. Safeguard ties build-time tool versions into your software bill of materials, so when a new Git advisory like CVE-2021-21300 lands, you can immediately query which builds, pipelines, and artifacts were produced with vulnerable tooling rather than manually auditing every runner.
• Continuous vulnerability intelligence. Safeguard tracks CVEs affecting the software supply chain toolchain itself — not just application dependencies — so filesystem-level and VCS-level issues like symlink attacks and race conditions in clone/checkout logic get the same prioritized attention as a vulnerable npm or PyPI package.

CVE-2021-21300 was patched years ago, but the pattern it represents — a filesystem race condition quietly undermining assumptions baked into everyday developer tooling — keeps recurring. Treating your Git clients, CI runners, and build images as first-class assets in your supply chain security program, not just the code they check out, is the durable lesson worth carrying forward.