A surprising and quietly dangerous edge-case in Git’s local clone optimization has been tracked as CVE-2024-32020: when a repository is cloned locally (source and target on the same filesystem), Git’s speed-saving behavior can create hardlinks into the new clone’s object store that remain writable by the original repository owner. In plain terms: an untrusted user who controls the source repository can modify objects in a supposedly separate clone simply by changing the files they still own on disk. Microsoft’s public advisory calls out Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” but that statement is an attestation of fact for Azure Linux only — not a blanket guarantee that no other Microsoft product ships the same vulnerable component. This article explains exactly what the vulnerability is, why Microsoft named Azure Linux first, which other Microsoft artifacts you should treat as unverified until inspected, and pragmatic steps administrators and developers should take now to measure and reduce risk.
CVE-2024-32020 arises from an implementation detail in Git’s local-clone optimization. When you clone a repository by pointing Git at a local path, Git may try to avoid copying every object file by creating hardlinks to the source repository’s
If the source repo is owned by a different user, those underlying object files remain owned and writable by that other user. That ownership relationship creates a long-lived write channel: the untrusted user who owns the source can rewrite those object files later, and the cloned repository (which appears to be a separate copy) will observe the changed contents. In short: the clone is not isolated from the source owner’s future writes, and that can be weaponized to alter commit/object contents in the clone after the fact.
Key observable facts about the vulnerability:
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE-2024-32020 arises from an implementation detail in Git’s local-clone optimization. When you clone a repository by pointing Git at a local path, Git may try to avoid copying every object file by creating hardlinks to the source repository’s .git/objects files instead. Hardlinks are efficient — they save disk space and time — but they also mean the same physical file on disk can be accessed through two filesystem paths that appear to be independent repositories.If the source repo is owned by a different user, those underlying object files remain owned and writable by that other user. That ownership relationship creates a long-lived write channel: the untrusted user who owns the source can rewrite those object files later, and the cloned repository (which appears to be a separate copy) will observe the changed contents. In short: the clone is not isolated from the source owner’s future writes, and that can be weaponized to alter commit/object contents in the clone after the fact.
Key observable facts about the vulnerability:
- The problem only appears during local clones when Git uses the local-optimization path that creates hardlinks rather than doing a proper independent copy or transporting objects over a network protocol.
- The risk is pronounced on multi-user systems and shared build runners where an attacker has write access to a repository directory that might be cloned by other users.
- The issue was fixed in specific Git maintenance releases; upgrading to those versions eliminates the hardlink race/hijack path.
What exactly is at stake technically
To make the implications concrete:- Git’s object database is normally expected to be a content-addressed, immutable store: an object identified by its SHA-1/SHA-256 should not change out from under you. CVE-2024-32020 breaks that expectation when hardlinks bring object files from another user into your
.git/objectsdirectory. - An attacker with write access to the source repo’s filesystem can replace or modify linked object files or packs and thus influence what a later developer sees when they inspect or operate on the cloned repo.
- Attack scenarios include tampering with source files seen by build systems, injecting malicious code into CI artifacts, or creating confusing/dangerous histories in shared developer environments.
- Because the attack leverages standard filesystem hardlink semantics rather than a remote network exploit, it’s local rather than remote: adversaries must be able to place or control the source repository files on the same filesystem visible to the victim.
Why Microsoft named Azure Linux — and what that wording actually means
Microsoft’s MSRC entry for this CVE specifically states that Azure Linux includes the affected open-source library and is therefore potentially affected and that the company will update the CVE/VEX entry if additional Microsoft products are identified. That phrasing is important and precise:- It is an inventory attestation — Microsoft inspected the Azure Linux images/artifacts and verified the vulnerable upstream component was present. Customers running Azure Linux images therefore have an immediate, actionable result: treat those images as potentially affected until patched.
- It is not an exclusivity claim. Microsoft explicitly leaves open the possibility that other Microsoft products may contain the same vulnerable upstream component; they simply haven’t completed or published attestations for those artifacts yet.
- Practically speaking, large vendors (including Microsoft) often start public attestations with a subset of their product families they can inventory quickly — cloud OS images are frequently the earliest to be checked because they are packaged and maintained as coherent artifacts. Other artifacts (WSL kernels, hosted build images, containerized agents, developer tooling bundles) can take longer to inventory and map to CVE records.
Which Microsoft artifacts could plausibly carry the vulnerable Git code
If you are assessing exposure in a Microsoft-centered environment, consider these artifact classes as plausible places the vulnerable code could appear. Treat this list as where to look rather than a claim that they are definitively affected:- Azure Linux images (confirmed by Microsoft attestation).
- Azure Marketplace VM images and custom VM images that include distribution packages with Git.
- Azure DevOps / Azure Pipelines agents (Microsoft-hosted images typically include Git for source checkout and build tasks).
- Azure Kubernetes Service (AKS) node images or node host OS images that include Git for node-level operations or build tooling.
- Windows developer tooling that bundles or relies on Git: Visual Studio’s built-in Git tooling, Git for Windows installations that come with or are recommended by Microsoft products, and VS Code’s Git integration (which relies on an installed Git).
- Windows Subsystem for Linux (WSL / WSL2) distributions and the WSL kernel image (if distro packages or the kernel tree include affected components).
- Microsoft-managed security or endpoint agents on Linux (for example, any Defender/agent packaging that bundles open-source Linux tooling).
- Any Microsoft-provided appliance or platform image that includes a distro-level Git package.
Cross-checking and verification — what to look for
To determine whether a given machine or image is exposed, operational teams should perform a short, repeatable inventory and verification procedure:- Identify and locate the Git binary and packages:
- On Linux: check your package manager (apt, yum/dnf, zypper, rpm, pacman) for installed git packages; run
git --versionin a shell to find the shipped version. - On Windows: check the Git for Windows installation (
git --versionfrom a Developer Command Prompt), and check Visual Studio/VS installer options if you rely on the bundled Git. - For hosted agents, container base images, and prebuilt artifacts: inspect image manifests or the software list distributed by the vendor, or run a container/VM temporarily to query
git --version. - Match installed versions against the patched releases for CVE-2024-32020:
- The upstream Git fixes were published in maintenance releases; if your installed Git version is older than the listed patched releases, treat it as vulnerable until updated.
- If you cannot update immediately, use operational mitigations (see below).
- For Microsoft-supplied images and cloud artifacts, watch Microsoft’s VEX/CSAF entries and product attestations for updates; Microsoft has signaled it will add new products to the CVE record if additional impact is identified.
Practical mitigations and mitigations hierarchy
If an artifact is confirmed vulnerable (or you cannot quickly determine the version), prioritize mitigations in this order:- Patch first
- The definitive fix is to upgrade Git to a patched maintenance release published by the Git project or your Linux distribution vendor. Apply distro vendor packages or the Git upstream release that contains the fix.
- Avoid local clones from untrusted repositories
- Don’t run
git clone /path/to/untrusted/repowhere the path points to a repository owned by an untrusted user on the same filesystem. - Use the
--no-localflag to avoid the local fast-path when performing local clones; that forces Git to perform a proper transport/copy so hardlinks are not created. - Use
--no-hardlinksto force copying rather than hardlinking when cloning locally. - For CI and build systems
- Ensure build runners and hosted agents do not perform local clones of repositories they do not control. Where feasible, use network transport clones (HTTPS/SSH) instead of local path clones.
- Use ephemeral, single-tenant build agents for untrusted contributions (fork builds) and avoid shared long-lived workdirs where untrusted users could place a local repo that will be cloned by other users.
- Adjust policy and privileges
- Limit the ability of untrusted users to create repositories on shared filesystems that other users will clone. Reduce multi-tenant access to developer or build hosts.
- On multi-user systems, prefer repository workflows that fetch from networked endpoints rather than copying local paths.
- Audit and monitor
- Search for
.git/objectsthat are hardlinks sourced from other owners. File-system tools (ls -l, stat, find -samefile, debugfs) and OS-level auditing can detect suspicious cross-user hardlinks. - Monitor build logs and developer machines for unexpected changes in Git object contents, and treat anomalies as high-priority incidents.
- When in doubt, treat clones from archive packages cautiously
- Repositories distributed as zip/tar bundles containing a
.gitdirectory may be treated as untrusted; sanitize by performing an explicit clone over the network or in an isolated environment before bringing artifacts into production build environments.
Detection and rapid triage checklist for administrators
Follow this prioritized checklist for each artifact class you operate:- Determine whether the artifact runs a Linux distribution with a packaged Git installation (common for Azure Linux VMs, container images, and many cloud images).
- Run
git --versionor query the package manager to determine the installed Git version. - If version is older than the patched releases for CVE-2024-32020, mark the artifact as vulnerable and schedule immediate remediation.
- If you cannot patch immediately, enforce process mitigations: ban local path clones from untrusted sources, modify CI checkout steps to use
--no-localor--no-hardlinks, and reduce shared repositories on build hosts. - For Microsoft-managed environments (Azure images, hosted agents), check Microsoft’s product attestations and VEX/CSAF mappings as they are published and update your inventory mapping accordingly.
Why you should not assume “Azure Linux only”
Microsoft’s public attestation is useful precisely because it tells customers which product was checked and found to include the component. But that attestation is narrow by design: vendors publish attestations incrementally as they complete artifact mappings. From an operational perspective the correct stance is conservative: treat Azure Linux as confirmed, and treat other Microsoft artifacts as potentially affected until you or Microsoft verifies them. This is particularly important for:- Shared CI runners and hosted build agents that often have Git preinstalled for checkouts — these are high-value targets for an attacker who can plant or control a source repo on the same filesystem.
- Developer workstation tooling bundles (Visual Studio, Git for Windows) that might include versions of Git older than the patched releases; developer machines can be used to perform local clones across different user contexts.
- WSL distributions, Marketplace images, and appliances where the same underlying distro packaging is reused across different Microsoft products.
Recommended communication to security leaders and developers
When briefing technical and security leadership, be precise and actionable:- Say: “Microsoft has confirmed Azure Linux contains the affected library; they will update the CVE/VEX mapping if other Microsoft artifacts are found. We must treat Azure Linux as confirmed and our other Microsoft artifacts as unverified until we confirm their state.”
- Action items to assign:
- Inventory all hosts and images that run Git or include Git binaries; flag those running vulnerable Git versions.
- Patch Azure Linux images and coordinate with cloud teams to roll updated images or apply vendor patches.
- Update CI/CD pipeline checkout steps to use
--no-local/--no-hardlinksuntil agents are patched. - Notify developer teams about the risk of cloning
.gitdirectories from untrusted sources on shared machines. - Add a recurring task to check Microsoft’s published VEX/CSAF attestations and update the artifact mapping.
Bottom line and practical timeline
- CVE-2024-32020 is a realistic local-risk scenario: an untrusted user can maintain a covert write path into what appears to be a separate clone via hardlinks created by Git’s local-clone optimization.
- Microsoft’s public communication naming Azure Linux is an important and actionable attestation for that product family, but it does not imply exclusivity. Other Microsoft artifacts may also ship the same vulnerable component; customers must verify their own artifact inventory or rely on Microsoft to expand attestations.
- Immediate priorities for defenders: inventory, patch where possible, and apply safe clone policies (
--no-local/--no-hardlinks) on build agents and shared hosts. For Azure Linux customers, treat the image as affected and apply vendor patches or updates as distributed. - Operational best practice going forward: require explicit artifact-level verification rather than relying on single-product attestations. Use SBOMs, VEX/CSAF attestations, and automated inventory to reduce the time between disclosure and verified mitigation.
Source: MSRC Security Update Guide - Microsoft Security Response Center
