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

Git has released fixes for a flaw that can let a malicious repository execute attacker code on a machine that clones it recursively with submodules. The issue, tracked as CVE-2026-111760, was fixed in Git 2.56.1, with matching fixes in 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 and 2.55.1. The release also addresses five other vulnerabilities.

Main flaw and how it works

CVE-2026-111760 is an integer truncation in how Git handles its index. An extremely long path can pass Git's safety check, but Git writes it to disk under a shorter name that an attacker can set to .git. This can let an attacker replace a submodule's .git file with a symbolic link to a folder containing malicious hooks or configuration. Hooks are programs Git runs at set points, so once Git uses that folder, attacker code can run. Submodules matter because Git refuses to replace a .git folder with a symbolic link, but in a freshly cloned submodule, .git is a file.

The fixed versions refuse such extremely long paths before their length can be cut short.

Other vulnerabilities fixed

The releases also fix CVE-2026-113408, in which a malicious server can send a branch name with path traversal when someone clones an empty repository over Git protocol v2; with the files reference backend, a later update can write outside Git's reference folder. CVE-2026-114467 involves merging a tag with more than two GPG signatures, which corrupts stack memory and can cause denial of service. CVE-2026-114469 allows a binary patch expanding to a very large size to get past Git's patch size limit of about 1 GiB and crash Git with an out-of-bounds read. CVE-2026-105437 involves a very large merge with many conflicts and a large conflict-marker-size attribute, which can make Git write past the end of an undersized buffer and corrupt heap memory. CVE-2026-114466 involves three git fast-import features, rewrite-submodules-from, rewrite-submodules-to and export-pack-edges, that could be used to read arbitrary files or create files and add data to them; Git now rejects them in an input stream unless --allow-unsafe-features is set.

GitHub and GitLab notes

GitHub explained the fixes in a detailed write-up and has applied them to github.com and GitHub Enterprise Cloud. For GitHub Enterprise Server, they are in versions 3.19.15, 3.20.11, 3.21.9 and 3.22.4. Fixed versions of GitHub Desktop and the GitHub Copilot app are being prepared, and GitHub Codespaces and GitHub Actions will also get the fixed Git. Git for Windows had not released a version based on Git 2.56.1 as of Tuesday at 19:09 UTC, according to a check of its release tags by The Hacker News. GitLab, which assigned CVE-2026-105437, said code-hosting servers are most likely to be targeted through git merge-tree, and that the conflict-marker-size attribute can be set in a .gitattributes file committed to a repository.

Mitigation guidance

GitHub advises installing a fixed version from your operating system or Git distributor, and updating any app that ships its own copy of Git. Until a fixed version is installed, GitHub suggests steps that do not replace the fixes: clone only from servers you trust; do not recursively clone repositories you do not trust; do not merge content or tags you do not trust; and do not process binary patches or fast-import streams from sources you do not trust. For CVE-2026-105437, servers that cannot upgrade yet can add conflict-marker-size=7 to each repository's info/attributes file, or turn off those merge checks for untrusted repositories.

Sources: The Hacker News