Git safe.directory Bypass Enabling Code Execution on Mult...

Git's own safety net—the mechanism meant to stop a repository from silently hijacking commands run inside it—was itself broken for years before anyone noticed. CVE-2022-24765 is a local privilege and ownership-check bypass in Git that let any user on a shared or multi-user Windows system plant a malicious repository in a common location and have its configuration silently applied when another user (potentially an administrator or a service account) ran a Git command nearby. The result: arbitrary command execution under the victim's identity, triggered by nothing more than running git status or git log in the wrong directory.

This wasn't an exotic memory-corruption bug or a crafted-repo parsing flaw. It was a trust-boundary failure — Git simply never asked "does this repository actually belong to me?" before reading and acting on its configuration.

What Is CVE-2022-24765?

Git stores per-repository settings in a local .git/config file, and it happily reads and executes directives from that file the moment a Git command runs inside (or above) that repository — things like core.fsmonitor (runs an arbitrary command on nearly every Git operation), core.pager, core.hooksPath, and various filter/clean/smudge commands. Before the fix for CVE-2022-24765, Git performed no check on who owned that .git directory relative to the user invoking the command.

On a single-user workstation, that's a non-issue. On multi-user Windows systems, it's a serious problem. Windows environments routinely have world-writable or shared top-level locations — the root of C:\, C:\Users\Public, %ProgramData%, substituted drives, roaming profile shares, and Remote Desktop / Terminal Services home directories. Any low-privileged local user could create a .git folder in one of these shared paths, seed it with a hostile config, and wait. If a higher-privileged user, a scheduled task, or a build agent later ran any Git command from that directory (or Git's upward directory search happened to walk into it), the attacker's configuration would be trusted and executed — a classic ownership check bypass that turned a passive file drop into remote code execution against another account.

The same underlying flaw also bit Linux and macOS users in a related, widely felt way: containers and CI runners that mount a host-owned repository into a root-owned container (a very common Docker pattern) hit the identical trust gap, which is why the eventual fix generated so much collateral disruption across build pipelines when it shipped.

Affected Versions and Components

CVE-2022-24765 affects Git itself — the core git client and its packaging in Git for Windows — across essentially all versions prior to the April 2022 security release. The Git project patched the issue simultaneously across its maintained branches:

• Git 2.30.3
• Git 2.31.2
• Git 2.32.1
• Git 2.33.3
• Git 2.34.3
• Git 2.35.2

Any Git installation older than these point releases is considered vulnerable, including Git for Windows distributions and any downstream tool or IDE that bundles an older Git binary (GUI clients, embedded Git in editors, CI runner images, and container base images that pin an old Git version are all in scope).

It's also worth noting that the initial safe.directory fix wasn't the final word. A follow-up issue, CVE-2022-29187, was identified shortly after as a bypass of the new ownership check under specific path-handling conditions on Windows, and was addressed in the next round of releases (Git 2.35.3, 2.36.1, and later maintenance versions). Environments that stopped at the first patch without picking up the subsequent hardening release should treat their remediation as incomplete.

Severity: CVSS, EPSS, and KEV Context

NVD rates CVE-2022-24765 as High severity, consistent with a CVSS v3.1 vector reflecting local attack vector, low attack complexity, low privileges required, no user interaction, and high impact to confidentiality, integrity, and availability — the profile of a local user turning a shared filesystem quirk into full code execution as another account.

Exploitation requires local (or local-equivalent, such as container/CI) access to a shared path, which keeps the EPSS-predicted exploitation probability comparatively low relative to remotely triggerable vulnerabilities — there's no network vector here. CVE-2022-24765 has not been added to CISA's Known Exploited Vulnerabilities (KEV) catalog. That combination of "high severity, low remote likelihood" is exactly the profile organizations tend to under-prioritize — and exactly the profile that matters most in shared build infrastructure, jump boxes, Terminal Services environments, and CI runners where many identities cross paths on the same disk.

Disclosure Timeline

• Prior to April 2022: The Git project identified and privately worked through the ownership-trust gap affecting shared and multi-user filesystems, alongside a cluster of related Windows-specific issues (including installer and PATH-handling problems tracked under separate CVEs).
• April 12, 2022: Git published coordinated security releases (2.30.3, 2.31.2, 2.32.1, 2.33.3, 2.34.3, and 2.35.2) that introduced the safe.directory configuration option and the ownership check now enforced before Git trusts a repository's configuration. GitHub, GitLab, and other Git hosting and tooling vendors followed with advisories urging immediate upgrades, and many developers first encountered the change as a new "detected dubious ownership in repository" error.
• Following weeks: CVE-2022-29187 surfaced as a bypass of the initial ownership check under certain Windows path conditions, prompting a second round of fixes (2.35.3, 2.36.1, and equivalents) to close the gap fully.
• Ongoing: Downstream distributions, container base images, IDEs, and Git for Windows installers rolled out updated bundles through mid-2022 and beyond, though legacy images and pinned dependency manifests continued to reference vulnerable Git versions well after the fix was available — a pattern this class of vulnerability is especially prone to.

Remediation Steps

1. Upgrade Git. Move to Git 2.35.2 or later — and confirm you've also picked up 2.35.3/2.36.1 or newer to close the CVE-2022-29187 bypass. Check Git for Windows separately from any bundled Git in IDEs, GUI clients, or CI images; each has its own update cadence.
2. Configure safe.directory deliberately. Add specific trusted paths with git config --global --add safe.directory <path> rather than reaching for the blanket safe.directory = * workaround many teams applied under pressure to silence the new warning — that setting re-opens the exact bypass the patch was designed to close.
3. Avoid running Git as a privileged account in shared or world-writable directories. Don't invoke Git from C:\, C:\Users\Public, %ProgramData%, or other multi-tenant paths as an administrator or service account; keep repository operations inside per-user, correctly ACL'd directories.
4. Harden CI/CD and container configurations explicitly. Where a container or runner intentionally operates on a host-mounted, differently-owned repository, allowlist that exact path via safe.directory in the pipeline configuration instead of disabling the check globally on the image.
5. Treat "detected dubious ownership" warnings as signal, not noise. Investigate why Git flagged a path before suppressing the message — it usually indicates a real ownership mismatch worth understanding.
6. Audit your fleet for stale Git binaries. Golden images, dev laptops, build agents, and vendored toolchains are the most common place a pre-2.35.2 Git binary keeps quietly persisting long after the org believes it has patched.

How Safeguard Helps

CVE-2022-24765 is a textbook example of why software supply chain security can't stop at scanning application dependencies — it has to extend to the developer tooling and build infrastructure that produces and moves code in the first place. A vulnerable Git binary sitting on a shared build server or a Windows Terminal Services jump box doesn't show up in a typical SBOM, but it's exactly the kind of foothold that turns a low-severity misconfiguration into lateral movement across your engineering environment.

Safeguard continuously inventories the toolchain layer — Git versions, CI runner images, and build-agent configurations — across your fleet, flagging outdated or misconfigured installations before they become the entry point for an ownership check bypass or similar trust-boundary failure. We surface risky safe.directory configurations (including overly permissive wildcard entries introduced as quick fixes), correlate them against known CVEs like CVE-2022-24765 and its follow-on bypass, and give security and platform teams a prioritized, evidence-backed remediation queue instead of another noisy vulnerability list. For organizations running shared multi-user Windows build infrastructure or containerized CI on mounted volumes, that visibility is the difference between finding the gap yourself and having an attacker find it for you.

If you're unsure whether your build environment is still exposed to CVE-2022-24765 or its related bypass, Safeguard can help you find out — and fix it — before it's tested by someone else.