Git fixes six critical vulnerabilities in clone, merge, and patches

On November 10, 2026, the Git project disclosed six security vulnerabilities fixed in version 2.56.1, with backports to the maintenance series 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, and 2.50.2. The announcement was published on the GitHub Blog, written by Elijah Newren, Staff Software Engineer at GitHub and author of merge-ort, Git's default merge strategy since version 2.34.

The point that matters for everyday Git users: the flaws don't require any exotic action to be exploited. Cloning a repository with submodules, merging a tag, applying a binary patch, or running a git fast-import received from a third party are routine operations in any CI pipeline, code hosting service, or open source contribution workflow.

The six flaws, one by one

The most severe in practice is CVE-2026-111760. It exploits an integer truncation in how Git validates paths in the index: an extremely long path passes validation under one name but is written under a shorter one. An attacker uses this discrepancy to replace a submodule's .git file with a symbolic link pointing to a directory containing malicious hooks, which Git ends up executing during a recursive clone.

CVE-2026-105437 affects any service that merges untrusted content on behalf of the user, including hosting platforms. Git calculated the size of the merge's output buffer before writing the result, and this calculation could overflow when the merge involved many conflicts combined with a large conflict-marker-size attribute, leading to heap corruption.

CVE-2026-114466, in turn, touches a feature less used day to day but present in migration and automation scripts: git fast-import. Three features (rewrite-submodules-from, rewrite-submodules-to, and export-pack-edges) lacked the restriction that already existed for commands capable of accessing files outside the repository. Now they are rejected by default when they come from an untrusted stream, unless the caller explicitly enables --allow-unsafe-features.

What GitHub has already done and what's left to you

GitHub applied the fixes to github.com, GitHub Enterprise Cloud, and GitHub Enterprise Cloud with data residency even before the public announcement. For those running GitHub Enterprise Server on-premises, patches were released in versions 3.19.15, 3.20.11, 3.21.9, and 3.22.4, and GitHub's own recommendation is to update as soon as possible.

GitHub Codespaces and GitHub Actions will also receive fixed versions of Git, and GitHub coordinated releases of GitHub Desktop and the GitHub Copilot app with the updated binary. This covers GitHub's infrastructure, but it doesn't fix the Git installed on your machine, on your self-hosted runner, or embedded in any tool that bundles its own copy of Git.

In short: if you use local Git, your own CI, or any application that bundles Git (desktop clients, deployment tools, automation bots), GitHub's fix doesn't automatically protect you. Each installation needs to be updated.

How to update

The path recommended by the Git project is straightforward:

1. Install version 2.56.1 or the patch corresponding to your maintenance series (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, or 2.50.2) through your Linux distribution, Homebrew, the official Windows/macOS installer, or your package manager.
2. Update any application or service that bundles its own copy of Git, such as GUI clients, self-hosted CI tools, or bots that process repositories automatically.
3. Review automation scripts that use git fast-import with untrusted source data, since the default behavior now blocks the features cited in CVE-2026-114466.

For those who can't update right away, the Git advisory itself lists stopgap mitigations: clone only from trusted servers, avoid recursive clones of repositories from unknown sources, don't merge untrusted content or tags, and don't process binary patches or fast-import streams from unverified sources. None of these practices replaces the patch: they only reduce the exposure window until the update runs.

What remains open

The announcement does not provide proof of active exploitation in production for any of the six CVEs, and GitHub did not disclose numbers on how many customers or repositories were exposed before the patch. There is also no timeline in the text for when Linux distributions that package older Git versions (outside the listed series) will receive their own backports beyond what the project has already published.

It's worth remembering that operations like recursive clone, merging signed tags, and applying binary patches are common in automated pipelines that process pull requests from outside, a typical case for open source projects that accept external contributions. For those who maintain this kind of infrastructure, updating the Git used by CI runners should come before, not after, updating development machines.