The Git project released a set of maintenance versions on November 10 that fix 6 vulnerabilities at once. The most serious is CVE-2026-111760: cloning an attacker-controlled repository with git clone --recurse-submodules can run the attacker's code on your machine, and GitHub's advisory scores it 8.0 (high). The Git project says every version since 2.27.0 is affected. The fixed versions are 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1 and 2.56.1; versions older than 2.50 are affected too but no longer receive maintenance releases.

When each of the six flaws triggers

  • CVE-2026-111760: Git stores the length of a file path in a 32-bit field. An attacker builds an extremely long path that passes the path-safety check but is cut down to .git when written to disk. In a freshly cloned submodule .git is a file, so it gets replaced by a symbolic link to a malicious directory, and the hooks or configuration there are then executed. The trigger is a recursive clone of an attacker-controlled repository.
  • CVE-2026-113408: a malicious server uses protocol v2 to point HEAD at a name containing ../, and when you later run git commit, Git writes to a file outside the reference directory.
  • CVE-2026-114467: when a tag message carries more than two GPG signatures, git merge corrupts stack memory, which can cause a denial of service.
  • CVE-2026-114469: a binary patch that inflates far beyond 1 GiB slips past the size check, and git apply then reads out of bounds and crashes.
  • CVE-2026-105437: a heap overflow in the three-way merge code, triggered by a huge conflict-marker-size in .gitattributes combined with many conflicts; merge, rebase, cherry-pick and merge-tree all run this code.
  • CVE-2026-114466: several features of git fast-import could read and write arbitrary files; they are now disabled by default and need --allow-unsafe-features if you really use them. This is a backwards-incompatible change.

Why this matters on a server

  • Deploy scripts and CI: many scripts clone recursively. The Git project says such a malicious repository fails the checks on the major hosting platforms and cannot easily be pushed there, but it can sit on the attacker's own server, and an innocent-looking .gitmodules pointing at it is enough. In other words, the risk comes from submodules inside third-party repositories you depend on.
  • Self-hosted Git services: a hosting service checks on the server whether a merge is possible on behalf of its users. The announcement notes that the heap overflow in merging could be escalated to remote code execution on GitLab. GitHub says github.com is already fixed, and the fixed GitHub Enterprise Server versions are 3.19.15, 3.20.11, 3.21.9 and 3.22.4.
  • Distribution packages: as of November 12, 2.39.5 in Debian 12 and 2.47.3 in Debian 13 are still marked vulnerable. Old does not mean safe: going by upstream's range, the 2.34.1 that ships with Ubuntu 22.04 is affected as well and has to wait for the distribution to backport the fixes.

What you can do now

Check your version with git --version, upgrade as soon as your distribution's fixed package arrives, and update applications that bundle their own copy of Git. Until the patch is installed, GitHub's advice is to 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. GitHub also says these precautions do not replace installing the fixes. We covered the same kind of supply-chain risk in our report on the npm worm; typical deploy flows that pull code with Git are in deploying a Node.js app and our Docker primer; and if you suspect a deploy machine has already run unknown code, follow our intrusion check and hardening guide.