Git Patches Flaw That Lets Malicious Repositories Execute Code During Recursive Clones

The Git project has shipped fixes for a serious vulnerability that allows a booby-trapped repository to execute arbitrary code on a machine performing a recursive clone with submodules. Tracked as CVE-2026-111760, the bug stems from an integer truncation in Git's index handling: an overly long path can slip past Git's length checks but then gets written to disk under a truncated name, which an attacker can craft to read .git. Since a freshly cloned submodule stores .git as a file rather than a folder, this lets attackers swap it for a symlink pointing to a directory containing malicious hooks, which Git then executes automatically. The issue is resolved in Git 2.56.1, with backported fixes in 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, and 2.55.1; GitHub has already deployed the patch to github.com and GitHub Enterprise Cloud, with Enterprise Server fixes in versions 3.19.15, 3.20.11, 3.21.9, and 3.22.4, while Git for Windows had not yet released an updated build as of this week.

The same release batch addresses five additional flaws: CVE-2026-113408 (path traversal via malicious branch names during empty-repo clones over protocol v2), CVE-2026-114467 (stack corruption/DoS from tags with more than two GPG signatures), CVE-2026-114469 (an oversized binary patch bypassing Git's ~1 GiB limit, causing an out-of-bounds read), CVE-2026-105437 (heap buffer overflow during large merges with an inflated conflict-marker-size attribute, flagged by GitLab as most dangerous to hosting services running git merge-tree), and CVE-2026-114466 (fast-import features abusable for arbitrary file read/write, now blocked by default). Until systems are updated, GitHub recommends avoiding recursive clones, merges, or binary patches from untrusted sources, and servers can mitigate CVE-2026-105437 by forcing conflict-marker-size=7 in repository attributes.