The Git project has shipped fixes for a flaw that lets a malicious repository run code on a machine that clones it with submodules.
Tracked as CVE-2026-111760, the bug is an integer truncation in how Git handles its index. A path long enough to overflow the stored length passes the project’s own safety check, then gets written to disk under a shorter name.
Why submodules open the door
The truncation lets an attacker decide the short name, and setting it to .git is the whole trick.
Git will not replace a .git directory with a symbolic link. But in a newly cloned submodule, .git is a plain file. An attacker can therefore point it at a directory holding malicious hooks or configuration, and hooks are programs Git executes automatically at defined points.
The blast radius is anyone who clones recursively from an untrusted source, and any pipeline that does so. That covers CI runners far more often than it covers individual developers.
Fixed releases are 2.56.1, plus 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 and 2.55.1 for the older maintenance lines. Each refuses the oversized path before the length can be cut short.
Defensive moves beyond the upgrade
Patch first, then reduce how often a recursive clone is automatic. Build jobs that fetch submodules from anywhere a pull request can reach deserve a manual gate.
Treat the vulnerability as a supply chain issue rather than a developer-laptop one. Blocking a clone is cheap; auditing a build server after a hook fired is not.
