Git Patches CVE-2026-111760: Malicious Repositories Could Execute Code During Recursive Clones

Developers who habitually run git clone --recursive against unfamiliar code have a fresh reason to be careful. The Git project has released a set of updates addressing a vulnerability that could allow a crafted repository to execute an attacker's code on the machine of anyone who clones it along with its submodules.

The issue, tracked as CVE-2026-111760, was fixed this week in Git 2.56.1, with backported patches for the 2.50 through 2.55 release series landing as 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, and 2.55.1. The Git project disclosed the flaw alongside the fixes, and the details were reported by The Hacker News.

What the Vulnerability Is

At the root of CVE-2026-111760 is an integer truncation in how Git handles its index — the internal data structure that tracks the working tree and staged changes. Truncation bugs occur when a value too large for its destination type is silently narrowed, producing an unexpected result rather than an error. In Git's case, that mishandling can be triggered by a repository crafted to exploit the flaw, and the consequence is code execution during a recursive clone.

The recursive-clone angle is what makes this notable. A plain git clone fetches a single repository, but --recursive (or --recurse-submodules) also pulls in every submodule the repository references and checks them out. Each submodule is itself a repository, so a single parent project can cause Git to process many nested repositories in one operation — and an attacker controls all of that content if they control the parent repository.

That combination — attacker-supplied repository data processed automatically by a developer's client — is the same trust boundary that has produced Git security issues before. Cloning is often treated as a read-only, low-risk action, which is exactly why malicious repositories remain an effective delivery mechanism.

Who Is Affected

Anyone running an unpatched Git version is potentially exposed. The maintainers clearly considered the issue serious enough to patch across seven release lines simultaneously, covering versions from 2.50 onward through the current 2.56 branch. Organizations that pin a specific Git version in build images, CI runners, or developer workstations should check which line they are on and move to the corresponding fixed release.

The practical exposure is concentrated where recursive clones of external code are routine:

• CI/CD pipelines that clone third-party repositories or dependencies, sometimes with submodules enabled by default.
• Developer workstations where engineers clone sample projects, forks, or tooling repositories without inspecting them first.
• Build systems and container images that bundle an older Git binary and are rebuilt infrequently.

Remediation and Mitigation

Upgrading is the primary fix. Administrators should move to Git 2.56.1, or to the matching patch release for their series (2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, or 2.55.1). Because Git is frequently installed through package managers and base images, verifying the actual binary version in use matters as much as updating a manifest — git --version on the host, inside containers, and on CI runners is a quick sanity check.

Where immediate upgrades are not possible, reducing reliance on recursive clones of untrusted content lowers risk. Cloning without --recursive and inspecting submodule definitions before initializing them gives a reviewer a chance to see what would be fetched. Restricting which repositories pipelines may clone, and pinning submodules to reviewed commits, are sensible controls regardless of this specific bug.

The Bigger Picture

CVE-2026-111760 is a reminder that the software supply chain begins at the clone. A repository is not inert data — it is input to a complex parser, and parsers have bugs. When that parser is invoked automatically on attacker-controlled content, memory-safety and integer-handling flaws become remote code execution.

For defenders, the takeaways are straightforward: track Git releases as security-relevant infrastructure, not just developer tooling; audit where recursive clones occur in automation; and treat "just clone it and take a look" as an action with a real attack surface. The patches are available now, and applying them promptly is the most effective step.

Original source: The Hacker News — Git Patches Flaw That Lets Malicious Repositories Execute Code During Recursive Clones