git clone --recursive can run code: six flaws fixed in Git 2.56.1 and what to check in your CI

For most of us, git clone is muscle memory. We run it to poke at a library, try a pull request locally or build a project in CI, without a second thought. The security release the Git project announced on November 10, 2026 is a good reason to pause that reflex: cloning a repository together with its submodules can run an attacker's code on your machine if the repository is malicious.

The release fixes six separate issues, not just one. Below is what changed, which scenarios carry real risk, and what to look at in your CI/CD setup in particular.

What happened

Git 2.56.1 is out, and the same fixes were backported to the 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 and 2.50.2 maintenance releases. GitHub says fixes are already live on github.com and GitHub Enterprise Cloud, and GitHub Enterprise Server is patched in 3.19.15, 3.20.11, 3.21.9 and 3.22.4. GitHub Desktop, the Copilot app, Codespaces and Actions are getting the updated Git as well.

The announcement doesn't say any of these flaws have been exploited in the wild. But the details are public now, and with bugs like these a working exploit usually doesn't take long to appear once a patch ships.

The headline issue: CVE-2026-111760

The most notable flaw comes from an integer truncation in how Git handles its index. Roughly:

1. The attacker puts an extremely long path into the repository.
2. Git validates the path in its long form, and the check finds nothing wrong.
3. When the path is written to disk, its length gets truncated, so the file lands under a much shorter name. The attacker can arrange for that name to be .git.
4. That lets them replace a submodule's .git file with a symlink to a directory holding their own hooks or config.
5. As soon as Git uses that directory, the attacker's hook runs.

The lesson goes beyond Git. Checking a value in one form and then using it in another is a classic way to get around security checks. The fix follows from that: patched versions reject overlong index paths before any truncation happens.

The key precondition is that a malicious repository has to be cloned recursively, together with its submodules. These are the commands at risk:

git clone --recurse-submodules <repo>
git submodule update --init --recursive

A plain git clone doesn't trigger this bug. However, plenty of tools and CI steps initialise submodules for you without making it obvious.

The other five fixes

The remaining issues mostly concern servers and hosting services:

• CVE-2026-113408: When an empty repository was cloned over protocol v2, Git didn't validate the HEAD target the server advertised. A malicious server could send a name containing path traversal, and with the files ref backend a later branch update could write outside the refs directory.
• CVE-2026-105437: Merges with many conflicts and a large conflict-marker-size value could overflow a size calculation and corrupt the heap. According to The Hacker News, GitLab assigned this CVE and code hosting servers running git merge-tree are the most likely targets.
• CVE-2026-114467: Merging a tag carrying more than two GPG signatures could corrupt the stack and cause a denial of service.
• CVE-2026-114469: A compressed binary patch could expand past Git's roughly 1 GiB limit, leading to an out-of-bounds read and a crash.
• CVE-2026-114466: Three git fast-import features (rewrite-submodules-from, rewrite-submodules-to, export-pack-edges) allowed arbitrary file reads or file creation from untrusted input. They're now rejected unless you pass --allow-unsafe-features.

If you run your own Gitea, GitLab or similar server, any service that merges on behalf of users is directly affected by this list.

Why it matters

Git isn't just something that runs in a developer's terminal anymore. It runs inside IDEs, desktop clients, package managers, CI runners and, more and more, coding agents. That has three practical consequences:

• "The system Git" isn't the only Git. Updating your OS package doesn't update the copy bundled with your IDE or desktop client. Both GitHub and The Hacker News stress that applications shipping their own Git need separate updates. When The Hacker News checked, Git for Windows hadn't shipped a 2.56.1-based release yet, so Windows users should keep an eye on that.
• CI is the biggest attack surface. A pipeline that builds pull requests from forks processes untrusted repositories by definition. If the runner holds deploy keys or broadly scoped tokens, a hook that fires during checkout can reach them.
• Coding agents are a new trigger. Ask an agent to "take a look at this repo" and it may well run a recursive command to initialise submodules. The Git version in the agent's environment belongs in your inventory too.

What to do in practice

1. Check the Git version everywhere. Not just on your laptop, but in CI images, Docker base images, self-hosted runners and servers:

git --version

You want 2.56.1 or the patched release for your series (for example 2.55.1, 2.51.3 or 2.50.2). If you rely on your distribution's package, confirm from its security advisory whether the fix was backported, because the version number alone can mislead you.

2. Inventory recursive submodule usage. Search scripts and pipeline definitions for --recurse-submodules and --recursive. In GitHub Actions look for submodules: recursive on actions/checkout, and in GitLab CI for GIT_SUBMODULE_STRATEGY: recursive. Turn them off where you don't actually need them.

3. Open untrusted repositories step by step. If you can't patch right away, clone without submodules first, check that the sources in .gitmodules are what you expect, and only then initialise submodules.

4. Separate privileges in CI. Keep secrets out of jobs that only build and test, use ephemeral runners where you can, and move deployment rights into a separate job. That's good hygiene regardless of this bug, and it limits the blast radius of the next one.

5. Server-side stopgap. Until you can patch for CVE-2026-105437, the suggested mitigation is adding conflict-marker-size=7 to each repository's info/attributes file, or disabling merge checks for untrusted repositories. Neither replaces the patch; they just cover the gap.

Bottom line

There's no need to panic here. No exploitation has been reported, and the most serious flaw requires a specific condition. But that condition, cloning with submodules, shows up in CI pipelines and automation more often than we tend to assume. I'd use this week to find out exactly which Git version runs on every machine, image and tool your team depends on.