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

Vulnerability / Software Security A flaw in Git can let a malicious repository run an attacker's code on a computer that clones it recursively, together with its submodules. The Git project fixed it this week in Git 2.56.1, with matching fixes for the 2.50 through 2.55 series in 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 and 2.55.1. The flaw, tracked as CVE-2026-111760, is an integer truncation in how Git handles its index. An extremely long path in a repository can pass Git's safety check, but Git then writes it to disk under a shorter name that an attacker can set to .git. This lets an attacker replace a submodule's .git file with a symbolic link to a folder holding malicious hooks or configuration. Hooks are programs Git runs at set points, so once Git uses that folder, the attacker's code can run. Submodules matter here 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, listed in the Git project's release announcement, refuse such extremely long paths before their length can be cut short. GitHub, which ships Git in its own tools, explained the fixes in a detailed write-up. It advises installing a fixed version from your operating system or Git distributor, and updating any app that ships its own copy of Git. The company has already applied the fixes 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. 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, a check of its release tags by The Hacker News found. Until a fixed version is installed, GitHub suggests these steps, which 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. Do not process binary patches or fast-import streams from sources you do not trust. The Git releases also fix five other flaws: CVE-2026-113408: When someone clones an empty repository over Git protocol v2, a malicious server can send a branch name that contains path traversal. With the files reference backend, a later update to that branch can then write outside Git's reference folder. CVE-2026-114467: Merging a tag that carries more than two GPG signatures corrupts Git's stack memory and can cause a denial of service. Hosting services that run such merges for users may also be affected. CVE-2026-114469: A binary patch that expands to a very large size can get past Git's patch size limit of about 1 GiB and crash Git with an out-of-bounds read. CVE-2026-105437: A very large merge, with many conflicts and a large conflict-marker-size attribute, can make Git write past the end of a buffer that is too small, corrupting heap memory. CVE-2026-114466: Three git fast-import features, rewrite-submodules-from, rewrite-submodules-to and export-pack-edges, could be used to read arbitrary files or to create files and add data to them. Git now rejects them in an input stream unless --allow-unsafe-features is set. GitLab, which assigned CVE-2026-105437, said code-hosting servers are most likely to be targeted through git merge-tree. A server may run that command to check whether a pull or merge request can be merged. The conflict-marker-size attribute can be set in a .gitattributes file committed to a repository. If a server reads attributes from the repository, any user who can push branches and open a pull or merge request can trigger the flaw. As a workaround for this flaw, 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. Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.