Git 2.56.1 fixes CVE-2026-111760 and five more flaws: update now

Git has shipped a security release that fixes six vulnerabilities, one of them a code-execution bug in recursive clones (CVE-2026-111760). The fixes are in Git 2.56.1 and in backports to 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 and 2.50.2, according to GitHub's announcement of 10 November 2026 and the Git project's own release notes. If you clone repositories you did not write, merge tags from others, or run a service that does either on behalf of users, update now.

Key points

• Six CVEs are fixed: CVE-2026-111760, CVE-2026-113408, CVE-2026-114466, CVE-2026-114467, CVE-2026-114469 and CVE-2026-105437.
• The most serious described is CVE-2026-111760: a recursive clone of a malicious repository can lead Git to run attacker-controlled config or hooks.
• Fixed versions: 2.56.1, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 and 2.50.2. GitHub Enterprise Server fixes are in 3.19.15, 3.20.11, 3.21.9 and 3.22.4.
• GitHub's post gives no CVSS scores and no reporter credits, so we do not give a severity rating either.
• GitHub says github.com and Enterprise Cloud are already patched; GitHub Desktop and the Copilot app are being released with patched Git.

What to do

1. Check your version: run git --version. If it is older than the fixed release in your series (for example 2.56.0 rather than 2.56.1), update.
2. Update through your package source: Linux distributions, Homebrew, Git for Windows and Xcode command line tools ship Git on their own schedules, so check that your channel carries the patched version. We could not confirm from the sources below when each distribution will ship it.
3. GitHub Enterprise Server admins: upgrade to 3.19.15, 3.20.11, 3.21.9 or 3.22.4 (whichever matches your series). GitHub urges upgrading as soon as possible.
4. If you cannot update yet, GitHub lists these precautions, and says they do not replace the fixes: clone only from trusted servers, avoid recursive clones of untrusted repositories, avoid merging untrusted content or tags, and avoid processing binary patches or fast-import streams from untrusted sources.
5. CI and build systems: these are the places that most often clone, merge and import automatically. Make sure the Git inside your runner images, containers and Codespaces-style environments is updated too. GitHub says Codespaces and Actions will receive patched Git versions.

What happened

On 10 November 2026 GitHub published "Git security vulnerabilities announced", written by Elijah Newren, describing six flaws and the releases that fix them. The Git project's release notes for v2.50.2 list the same six identifiers with the same descriptions, and the notes for v2.56.1 say that release merges in the security fix first shipped in the older maintenance versions.

The six, in the order GitHub lists them:

CVE-2026-111760, code execution during recursive clones. An integer truncation in Git's index handling lets an extremely long path pass validation under one name and then be written under a shorter one. An attacker can use that to replace a submodule's .git file with a symbolic link pointing at a directory that contains malicious configuration or hooks, which Git may then execute during a recursive clone. The fix rejects extremely long index entry paths before their lengths can be truncated. GitHub's advisory reference is GHSA-vp2w-7xxj-jvxr.

CVE-2026-113408, path traversal through a server's advertised HEAD. When cloning an empty repository over protocol v2, a server can advertise a HEAD symbolic reference to an unborn branch. Git did not validate that target. The Git release notes give the example of a name like refs/heads/../../../TARGET. With the files reference backend, a later branch update can write outside the reference directory. Git now validates the advertised target, and the release also validates other reference names and symbolic-reference targets received over protocol v2.

CVE-2026-114467, stack corruption when stripping signatures. Git assumed a message carries at most two GPG signatures. A crafted message with more can write past the end of a fixed-size stack array, causing memory corruption and possibly a crash. The realistic trigger is merging a tag that carries more than two signatures. GitHub notes hosting services that perform merges for users may be affected too. The fix removes the fixed-size array.

CVE-2026-114469, out-of-bounds reads when applying binary patches. Git rejects patches over roughly 1 GiB, but it checked only the supplied (compressed) size. A binary patch that inflates beyond the limit slipped past, and could trigger an out-of-bounds read that crashes Git. Git now also checks the declared uncompressed size.

CVE-2026-105437, heap corruption during large merges. The memory size calculation for merge output can overflow when results are very large, for example many conflicts combined with a large conflict-marker-size attribute. Git could then allocate too small a buffer and write past it. The fix uses size-appropriate types and checked arithmetic, and rejects merges whose output size cannot be represented safely. This affects local merges as well as services that merge untrusted content.

CVE-2026-114466, filesystem access through fast-import streams. Three features of git fast-import lacked the protection already applied to untrusted input: rewrite-submodules-from and rewrite-submodules-to can read arbitrary files (possibly exposing contents through error messages), and export-pack-edges can create files or append to existing ones. They are now rejected from input streams unless the caller passes --allow-unsafe-features. GitHub's advice is to enable that only when you trust the program generating the stream. The older export-marks feature was already disabled by default.

GitHub also describes extra hardening: overflow checks on related index entry allocations during checkout and tree processing, so allocation sizes cannot be truncated or overflow before Git copies a path into memory.

Background

Recursive-clone and submodule path tricks are a recurring class of Git bug. GitHub's own blog has published a series of "Git security vulnerabilities announced" posts, and this is the seventh in that numbering (the address ends in -7). The common thread is that Git treats a repository as data, but a repository can contain things Git acts on: hooks, submodule definitions, symbolic links and configuration. Whenever a path check can be fooled, "data" can become "code".

What is different here is the mix: one clone-time code execution path, one protocol-level path traversal, and four memory-safety or input-handling bugs in less common commands (merge, apply, tag signatures, fast-import). Most developers will meet the first two in ordinary use. The rest matter most for servers and automation that process other people's input.

How the attack paths compare

Bug	You are exposed when you...	Likely impact described
CVE-2026-111760	recursively clone an untrusted repository	code execution via hooks/config
CVE-2026-113408	clone an empty repository from an untrusted server over protocol v2, then update the branch	file write outside the ref directory
CVE-2026-114467	merge a tag with more than two signatures	stack corruption, crash
CVE-2026-114469	apply a crafted binary patch	crash via out-of-bounds read
CVE-2026-105437	merge very large or untrusted content	heap corruption
CVE-2026-114466	process an untrusted fast-import stream	arbitrary file read, file creation or append

The table is our summary of GitHub's descriptions. It is not a severity ranking: neither source rates the bugs, and we have not seen working exploits described.

What it means

For individual developers the practical rule is the old one: do not recursively clone things you do not trust, and keep Git current. A clone-time code execution bug is the kind that turns "let me look at this repository" into a compromise, so security researchers, students running other people's course repositories, and maintainers triaging pull requests have the most reason to update first.

For platform teams the larger exposure is automation. CI runners, build farms, code-review bots, mirroring services and anything that merges on behalf of users all run Git against content they did not choose. GitHub says its hosted services are patched; self-hosted runners, internal Git servers and container base images are on you.

For Linux distribution users, the date you get the fix depends on your maintainer. The Git project backported to six older maintenance series precisely so that distributions on older versions can pick up a small patch instead of jumping to a new feature release.

What we don't know yet

• Severity. GitHub's post gives no CVSS scores. We expect the CVE records to add them.
• Who found the bugs. The post names no reporters.
• Exploitation in the wild. Neither the GitHub post nor the release notes say whether any of these bugs has been used in attacks. Do not assume either way.
• The exact release date. GitHub's post is dated 10 November 2026, but the git-scm.com front page, when we read it, listed Git 2.56.1 as dated 2026-10-26. The release notes for 2.56.1 do not describe the vulnerabilities themselves. We have not resolved the difference; if you track release dates for compliance, check the tag in the Git repository.
• Affected ranges. GitHub gives fixed versions but no explicit "affected" range. Treat anything older than the fixed release in your series as unpatched.
• Distribution timing. We could not confirm when Debian, Ubuntu, Red Hat, Homebrew or Git for Windows ship fixes.

What to watch next

• Your distribution's security tracker for the six CVE numbers.
• CVSS scores and any proof-of-concept write-ups for CVE-2026-111760.
• GitHub Desktop, Codespaces and Actions runner updates, which GitHub says are coming.
• GitHub Enterprise Server 3.19.15, 3.20.11, 3.21.9 and 3.22.4 in your own change window.

Sources

• GitHub Blog: Git security vulnerabilities announced (primary)
• Git release notes v2.56.1
• Git release notes v2.50.2
• git-scm.com (release listing)