Six Git Vulnerabilities Fixed in Git 2.56.1: CVEs and Patch Checklist
The Git project released Git 2.56.1 on November 10, 2026, to fix six vulnerabilities. The most urgent issue for teams that clone unfamiliar repositories is a path-validation bug that can execute code during a recursive clone. Other fixes cover malicious servers, merges, binary patches and fast-import streams. Update the Git executable each workflow actually runs, including bundled copies and build images.
Which Git releases include the fixes?
Git 2.56.1 includes the fixes. The project also published backports in 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 and 2.50.2. Linux distributions may ship patches in packages whose upstream version prefix looks older. Verify the package revision against the distribution’s security notice before classifying a machine as vulnerable or patched. GitHub disclosure · Git 2.56.1 release.
The six CVEs and how the fixes work
| CVE | Trigger and previous behavior | Fix and impact |
|---|---|---|
| CVE-2026-111760 | A recursive clone of a malicious repository can hit an index path length that changes during handling. That discrepancy can let a submodule resolve attacker-controlled metadata and execute code. | Git rejects excessively long index entry paths before truncation can change the path being validated. |
| CVE-2026-113408 | A malicious protocol v2 server advertises a crafted unborn HEAD during an empty clone. With the files reference backend, a later reference write can escape the intended directory. | Git validates the advertised target and other reference names received through protocol v2. |
| CVE-2026-114467 | Removing signatures from a crafted message, for example during a tag merge, can overrun a stack array when the signature count exceeds two. | The signature handling no longer uses a fixed two-entry array. This addresses memory corruption and potential service denial. |
| CVE-2026-114469 | A compressed binary patch can expand beyond the size the patch code can safely handle. The old check considered the supplied patch size. | Git checks the declared uncompressed size before processing. The disclosed impact includes an out-of-bounds read and a crash. |
| CVE-2026-105437 | A very large merge result can overflow the allocation calculation, leading to heap corruption. Services that merge untrusted input can be exposed too. | Git uses size-appropriate types and checked arithmetic and rejects outputs that cannot be represented safely. |
| CVE-2026-114466 | Untrusted fast-import streams can use certain features to read or write files outside the repository, depending on the feature and process permissions. | The affected stream-supplied features are rejected unless unsafe features are explicitly enabled. Keep that override off for untrusted streams. |
The announcement also describes overflow hardening in related index allocation paths. Check the advisories linked from the disclosure for exact conditions and package-specific scope. The maintenance versions above are patch targets, not a claim that every older release is affected identically by every CVE.
What should GitHub and CI administrators patch?
GitHub says it deployed fixes to GitHub.com, GitHub Enterprise Cloud and the data-residency service. It lists GitHub Enterprise Server versions 3.19.15, 3.20.11, 3.21.9 and 3.22.4 as patched targets. It is coordinating releases for GitHub Desktop and the Copilot app with bundled Git. Check each application’s own release channel. Installing a new system Git does not establish that a desktop app’s embedded binary has changed.
GitHub says Actions and Codespaces will receive patched copies. Verify the binary inside an actual job because self-hosted runners, job containers, custom images and steps that modify PATH can resolve a different copy. If a checkout occurs before diagnostics, verify the binary ahead of that step. Also review workflows that merge pull requests, apply third-party patches, import repository dumps or initialize submodules.
How to verify and update Git
On Windows PowerShell:
On Linux or macOS:
Use the official Git downloads page or your existing package channel. On Windows, update through the Git for Windows installer or the package manager that installed it. On Linux, use your distribution’s security updates and confirm the patched package revision. On macOS, distinguish Homebrew Git from the Git bundled with Apple’s developer tools. Update the relevant installation and rerun the path and version checks.
For containers, rebuild from a patched base or update the pinned package in the image definition. Redeploy and run the verification inside the replacement image. For self-hosted runners, check the executable under the runner service account. A shell opened as an administrator can use a different PATH from the runner.
Until an exposed environment is patched, suspend unnecessary processing of untrusted repositories, recursive submodules, binary patches and import streams. Keep source-processing jobs isolated from deployment credentials. These controls reduce exposure while the package is replaced. Related background is available in the ASP.NET PB IIS deployment guide.
FAQs
Is Git 2.56.0 sufficient? Use 2.56.1, an official patched maintenance release, or a vendor package whose advisory confirms the backport.
Does updating Git on my laptop fix Actions? Check the Git inside the runner and job container independently. A local install only updates that installation.
Should I test an exploit to confirm the patch? Use trusted release and package metadata plus a normal checkout smoke test. An exploit is unnecessary for version verification.
Comments
Post a Comment