Git fixes flaw that lets malicious clones execute code

A flaw in Git, tracked as CVE-2026-111760, could allow a malicious repository to execute code during recursive clones, including submodules. The issue centres on an integer truncation in Git’s handling of its index: an extremely long path can pass safety checks but then be written to disk under a shorter name that can be set to .git. This enables an attacker to replace a submodule’s .git file with a symbolic link pointing to a folder containing malicious hooks or configuration.

Hooks are programs Git runs at certain points, so once Git uses that folder, the attacker’s code can run. The vulnerability is specifically relevant to freshly cloned submodules because Git’s treatment of .git differs between folders and files in that context.

Fixes have been applied in Git 2.56.1, with corresponding backports for the 2.50 through 2.55 series (2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 and 2.55.1). GitHub notes the fixes and has already deployed them to github[.]com and GitHub Enterprise Cloud. For GitHub Enterprise Server, affected versions are 3.19.15, 3.20.11, 3.21.9 and 3.22.4.

The Git project release announcement also lists five other CVEs resolved in the same updates, including CVE-2026-113408, CVE-2026-114467, CVE-2026-114469, CVE-2026-105437 and CVE-2026-114466.

As a temporary workaround where upgrades are not yet possible, sources recommend avoiding recursive clones of untrusted repositories and removing or restricting processing of content from unknown sources; alternatively, setting conflict-marker-size=7 in each repository’s info/attributes file can help mitigate certain scenarios.