Michael JohnsonIf you updated Git in your terminal, the job may not be finished: individual applications and build environments may run their own copy. On November 10, 2026, the Git project released fixes for six vulnerabilities, ranging from code execution during recursive cloning to memory corruption during merges. So check every environment that handles repositories or their contents—not just the result of git --version in your shell.
What changed in the update
The fixes are included in Git 2.56.1 and have been backported to supported branches: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, and 2.50.2. The update addresses six issues across different parts of Git, involving paths, links, signatures, binary patches, merges, and import streams. GitHub published its vulnerability analysis and upgrade recommendation on November 10; the Git 2.56.1 release notes list the CVEs fixed in this series.
The practical takeaway is to update Git in three places: on workstations, in automation, and inside applications that bundle their own Git build. That last item is easy to miss: updating the system package does not automatically change the versions in every client or build image.
Why recursive clone deserves attention
The clearest attack chain starts with recursively cloning an untrusted repository. Because of path-length truncation, a very long entry could pass validation under one name and then be written to disk under a shortened one. In the Git scenario described, this could replace a submodule’s .git file with a symbolic link to a directory containing malicious configuration or hooks. When Git accessed it later, it could execute attacker-supplied code.
For practical purposes, this requires a specially prepared repository and the relevant operation. Teams that regularly clone projects from external sources with the --recurse-submodules option should prioritize updating client and automation environments. The fix rejects excessively long paths before their length can be truncated.
Other places where Git handles untrusted data
Another issue arises when cloning an empty repository over Git protocol v2. A server could provide a HEAD reference with a branch name containing directory-traversal components; a later branch-update operation could then write a file outside the expected reference directory. Fixed Git versions validate that target and other reference names received over the protocol.
Separate vulnerabilities affected merge and patch operations. When processing signatures, a fixed-size array allowed for at most two signatures; a specially crafted message with more signatures could cause an out-of-bounds write and memory corruption. When applying a binary patch, the size check accounted for the original representation, even though compressed data can expand to a substantially larger size. Git now checks the declared uncompressed size before processing.
Large merges could also cause an overflow while calculating the required buffer size, followed by an out-of-bounds write. This includes cases involving hosting services and applications that merge untrusted content. Finally, three git fast-import features have been restricted for commands in the input stream: rewrite-submodules-from and rewrite-submodules-to could read arbitrary files, while export-pack-edges could create files or append data to existing ones. These features are now blocked unless the --allow-unsafe-features flag is explicitly specified; use it only with a trusted stream generator.
Where to look for separate Git copies
Developers can start by inventorying where Git is invoked. Check the terminal version, then use the built-in update checks for IDEs and desktop Git clients. Next, check CI images, containers, runners, and server jobs that clone, merge, apply binary patches, or run fast-import. Having a recent Git version on the host does not guarantee that an application uses it.
Organizations should check not only source images but also environments that are already deployed: a persistent runner or internal service may have retained an old binary after the base image was updated. For GitHub Enterprise Server, GitHub lists fixed versions 3.19.15, 3.20.11, 3.21.9, and 3.22.4. The company said it had already deployed fixes to github.com and GitHub Enterprise Cloud, including data-residency versions. Releases of GitHub Desktop and the GitHub Copilot app with the fixed Git are being coordinated; fixed versions for Codespaces and GitHub Actions are also still to come.
How to reduce risk before updating
If you cannot install the fix immediately, temporarily limit operations on untrusted data: clone repositories only from trusted servers, avoid recursive cloning of unverified projects, do not merge their contents, and do not apply binary patches or fast-import streams received from them. These measures reduce exposure to the specific vulnerable scenarios, but they do not replace an update.
The main practical takeaway is simple: look for the Git fix wherever a program actually runs Git. The terminal command is only one such place; development clients, CI, and repository-processing services each need to be checked separately.
