Git Local Clone Information Disclosure via Hardlinks (CVE...

CVE-2022-39253 is an information disclosure vulnerability in Git that turns one of the project's oldest performance tricks — hardlinking objects during a local clone — into a way to smuggle the contents of files a victim never intended to share. When Git clones a repository from a local filesystem path, it normally hardlinks object files from the source repository's .git/objects directory into the new clone rather than copying them, to save time and disk space. CVE-2022-39253 shows that if the source repository contains a symlink where Git expects a normal object-store entry, that hardlinking behavior can be tricked into linking in files from outside the repository entirely — including sensitive files elsewhere on the victim's filesystem — exposing their contents inside the resulting clone.

This is a textbook software supply chain risk: the danger isn't in code you wrote, it's in a repository you were persuaded to clone.

What Is CVE-2022-39253?

Git's local clone optimization kicks in automatically whenever the clone source is a local path or a file:// URL, and there is no explicit request to avoid it. Instead of copying every object, Git hardlinks the files that make up the source repository's object database into the destination .git/objects directory. Hardlinking is fast and disk-efficient, but it depends on an assumption: that everything under the source repository's object storage is a legitimate Git object, not something an attacker has staged there.

CVE-2022-39253 breaks that assumption. A malicious repository can be crafted so that a path Git expects to treat as part of its own object store is actually a symbolic link pointing somewhere else on disk — potentially at a file the attacker has no business reading, such as SSH keys, credential files, environment configuration, or other sensitive local data the cloning user can access. When the vulnerable Git client performs the local clone and follows that symlink while building hardlinks, the targeted file's contents end up embedded as an object inside the newly created clone. From there, anything that later inspects, shares, uploads, or publishes that clone — a CI artifact, a shared build cache, a repository pushed to a remote — can leak the disclosed data to the attacker.

Because the flaw requires a victim to actively run a local clone (or an equivalent operation, such as a recursive submodule checkout that triggers the local-clone code path) against attacker-controlled repository content, it sits in the category of vulnerabilities that depend on user interaction rather than being remotely triggerable over the network. That doesn't make it low-value to attackers, though — "clone this repo" is an extremely common ask in open source contribution workflows, onboarding scripts, CI pipelines, and package build systems, all of which routinely perform local clones without a second thought.

Affected Versions and Components

CVE-2022-39253 affects Git itself, across essentially every maintained release line prior to the coordinated security update. The fix landed in the following versions:

• 2.30.6
• 2.31.5
• 2.32.4
• 2.33.5
• 2.34.5
• 2.35.5
• 2.36.3
• 2.37.4
• 2.38.1

Any Git installation older than the corresponding patched release on its maintenance branch is vulnerable. Because the issue lives in core clone logic rather than a platform-specific feature, it affects Git on Linux, macOS, and Windows alike, along with any tooling that shells out to the git binary to perform local clones — package managers, monorepo tooling, CI runners, container build steps, and IDE integrations that fetch or mirror repositories from local paths.

Severity: CVSS, EPSS, and KEV Context

NVD scored CVE-2022-39253 with a CVSS v3.1 base score of 5.5 (Medium), using the vector AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. That breaks down cleanly: the attack requires local-vector conditions and user interaction (the victim has to clone the malicious content), but once triggered the confidentiality impact is high — arbitrary file contents can be exposed — while integrity and availability are unaffected. GitHub's own advisory, GHSA-mvvc-r97q-hjrq, labeled the issue "Moderate" severity, consistent with that scoring.

The vulnerability does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no public evidence of active, widespread exploitation. Its EPSS-style exploitation likelihood tracks low, which lines up with the nature of the bug: it needs a victim to knowingly clone a specific, crafted repository rather than being reachable through a network listener or an automatically-triggered code path. That said, "low likelihood of mass exploitation" is not the same as "low relevance" — targeted supply chain attacks are exactly the scenario where a bug like this earns its keep, since the entire premise of a supply chain attack is convincing someone to pull in content they trust.

Disclosure Timeline

Git's maintainers disclosed CVE-2022-39253 as part of a coordinated security release on October 18, 2022, alongside a related fix (CVE-2022-39260, a separate buffer overflow issue in git shell). The project shipped patched point releases across every actively maintained line — from 2.30.6 through 2.38.1 — on that date, and GitHub published the corresponding security advisory (GHSA-mvvc-r97q-hjrq) with the technical description and remediation guidance. In the days and weeks that followed, downstream Linux distributions, package managers, and Git-hosting platforms rolled updated Git packages and runtime images into their own release cycles, as is typical for a core VCS tooling fix that touches nearly every environment running Git.

Remediation Steps

Fixing CVE-2022-39253 is straightforward once you know it's there — the challenge, as usual with software supply chain vulnerabilities, is knowing where an old Git binary is still quietly running.

1. Upgrade Git. Update to the patched release for your branch (2.30.6, 2.31.5, 2.32.4, 2.33.5, 2.34.5, 2.35.5, 2.36.3, 2.37.4, 2.38.1, or later). This is the only complete fix.
2. Audit build and CI images, not just developer laptops. Container base images, CI runner AMIs, and build-agent VMs frequently pin an older Git version and go unpatched far longer than workstation software. These are also the systems most likely to perform unattended local clones of third-party repositories or submodules.
3. Apply the interim workaround if you can't patch immediately. Per the official advisory, avoid using --local or file://-based cloning against repositories of unknown or untrusted provenance. Preferring the network transport (or --no-local) forces Git down a path that doesn't rely on the vulnerable hardlink logic.
4. Treat submodules with the same suspicion as top-level clones. Recursive submodule fetches can invoke the same local-clone code path, so a malicious submodule reference is just as viable an attack vector as a malicious top-level repository.
5. Review any artifacts produced by clones of untrusted sources before that period's patch, if applicable. If a local clone of an untrusted repository ran on a vulnerable Git version, treat the resulting clone as potentially containing exfiltrated file contents until proven otherwise.

How Safeguard Helps

CVE-2022-39253 is a good illustration of why software supply chain security has to extend past application dependencies and into the tooling that builds and moves your code. A vulnerable Git binary sitting in a CI image, a build container, or a developer environment is invisible to most dependency scanners because it isn't a package your application declares — it's infrastructure everyone assumes is fine.

Safeguard's platform is built to close exactly that gap. By continuously inventorying the toolchains present in build environments, CI/CD runners, and container images — not just application-level dependencies — Safeguard can flag outdated or vulnerable Git installations, including versions affected by CVE-2022-39253, before they become the quiet entry point for a targeted attack. That visibility extends to:

• Toolchain and build-environment scanning that identifies vulnerable Git versions across CI runners, build agents, and developer machines, tied to known CVEs like this one.
• Policy enforcement in the pipeline, so builds relying on a vulnerable Git binary can be gated or flagged before they run, rather than discovered after the fact.
• Provenance and repository-source monitoring, giving teams visibility into where local clones, submodule fetches, and untrusted repository ingestion happen inside automated workflows — the exact conditions this vulnerability depends on.
• Continuous vulnerability tracking, so once a fix like Git 2.38.1 ships, Safeguard can confirm remediation across every environment rather than relying on a one-time patch cycle that inevitably misses stale images.

Vulnerabilities like CVE-2022-39253 rarely make headlines, but they are precisely the class of issue that software supply chain attacks are built on: an ordinary, everyday action — cloning a repository — turned into a mechanism for information disclosure. Keeping Git current, minimizing local clones of untrusted sources, and maintaining real visibility into the tooling underneath your build pipeline are the practical defenses, and they're the same principles Safeguard applies across the rest of your software supply chain.