Git recently addressed a severe vulnerability that allows malicious repositories to execute attacker-controlled code on systems that perform recursive clones—including submodules. The flaw revolves around an integer truncation issue in Git’s path-length checks (tracked as CVE-2026-111760). Although a path may initially pass safety validation, Git might later write it to disk under a truncated name. This truncated name can be crafted by an attacker to become “.git,” which is forbidden in some contexts but unavoidable when a submodule’s “.git” starts as a file rather than a folder. In that state, attackers can create symbolic links, inject hooks or config files under the repository’s control, and trigger execution during operations like merging or building.
Where the Risk Comes From
One key detail is how Git treats submodules differently. In a newly cloned submodule, “.git” is represented as a file, not a folder—allowing it to be replaced by a symbolic link if the truncated path ends up being “.git.” That replacement means configuration files or hooks residing either in attacker-controlled locations or linked paths can execute without triggering standard folder-based protections.
Fixes, Other Issues, and Mitigation
Git version 2.56.1 patches CVE-2026-111760, and versions 2.50.2 through 2.55.1 include corresponding fixes for the vulnerable older branches. These updates refuse extremely long paths at the input stage—before any truncation can occur. Additional vulnerabilities patched recently include:
- An issue in Git protocol v2 where cloning an empty repo allows a malicious server to introduce branch names with path traversal, which can later write outside of Git’s reference directory.
- A scenario where merging a tag with more than two GPG signatures can corrupt memory and lead to denial of service.
- An excessive-size binary patch that bypasses Git’s 1 GiB patch-size limit and causes an out-of-bounds read.
- A flaw where very large merges with many conflicts and oversized conflict-marker attributes lead to buffer overflows and memory corruption.
- Unsafe fast-import features (rewrite-submodules-from/to and export-pack-edges) that permit reading or writing arbitrary files unless explicitly enabled.
Major Git-based platforms have begun applying fixes already. GitHub’s main services—including Enterprise Cloud—have been updated. Enterprise Server versions 3.19.15, 3.20.11, 3.21.9, and 3.22.4 also include fixes. GitHub is preparing updated builds for GitHub Desktop, Copilot, Codespaces, and Actions. As of the last check, Git for Windows hasn’t released its version based on 2.56.1 yet.
What You Can Do Now
Until all systems are updated, several precautions can reduce risk. Only clone repositories from trusted sources. Avoid recursive cloning of repositories where submodules might be unverified. Refrain from accepting or merging untrusted content—especially tags or binary patches, or streams from fast-import. For servers that can’t immediately upgrade, one workaround is to enforce a safe conflict-marker-size (for example, setting it to 7) via info/attributes, or disable unsafe merge checks for untrusted code.
Overall, this represents a wider trend: supply-chain risks and dependencies are only as secure as their weakest link. An attacker exploiting path-length truncation to hijack hooks or configurations in submodules is a textbook pivot through expected safety boundaries. This flaw shows how assumptions—such as “.git is always a folder,” or that tall paths remain validated—can be undermined in subtle ways. Watch for whether your development tools, CI/CD pipelines, or hosting services include these patched Git versions, and audit custom or embedded Git binaries. Even small negligence here can lead to large breaches down the line.
