Git patches flaw that lets cloned repositories run code

The Git project has released fixes for a flaw that allows a malicious repository to run an attacker's code on any machine that clones it recursively, together with its submodules. The fixes were published this week, according to a report on 10 November 2026 by The Hacker News. The bug is tracked as CVE-2026-111760.

The headline fix is in Git 2.56.1. The project has also shipped matching fixes for older release series, in versions 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 and 2.55.1. That spread of backports means the problem affects at least the 2.50 through 2.56 lines, and that administrators running pinned or distribution-packaged versions will need to check which point release they are on rather than assuming an upgrade to the latest major version is the only route.

According to The Hacker News, the underlying problem is an integer truncation in the way Git handles its index — the staging area file that records the contents of a working tree. Integer truncation happens when a value is stored in a smaller numeric type than it needs, so the top bits are silently discarded and the resulting number is wrong. In memory-handling code, a wrong size is a common route to memory corruption.

The attack path described is a recursive clone. A recursive clone is one where Git fetches not just the named repository but also its submodules, which are other repositories referenced by it and pulled in automatically. That means a user can trigger the flaw by cloning a single repository they chose to trust, while the hostile content sits in a dependency they never looked at.

Recursive cloning is routine in build pipelines, continuous integration runners and any automated system that pulls source code before running it. Those systems often clone repositories without a person reviewing the submodule list first.

The available reporting does not say who found the flaw, whether it has been exploited, or how difficult a working exploit would be to build. No proof-of-concept has been described in the source. The practical advice is unchanged by any of that: identify every host and container image that ships a Git client, confirm the version, and move to the relevant patched release. Build agents and developer workstations are both in scope, because both clone untrusted code as a matter of course.