Git 2.56.1 and six older releases fix six flaws; one lets a recursive clone run code, say the notes

Seven Git releases name the same six CVE ids

Git's own release notes for v2.50.2, v2.51.3, v2.52.1, v2.53.1, v2.54.1, v2.55.1 and v2.56.1 each name the same six CVE ids, CVE-2026-111760, CVE-2026-113408, CVE-2026-114466, CVE-2026-114467, CVE-2026-114469 and CVE-2026-105437. That is seven releases for six vulnerabilities (the count of releases is derived: 2.56.1 plus six backports). GitHub's post of 10 November 2026 says the project is releasing them "today", and says one of the six lets an attacker-controlled repository run code during a recursive clone. This briefing was written from pages read between 16:06 and 16:20 UTC on Wednesday 11 November 2026.

Git describes itself as a "free and open source" version control system. Its own release notes, GitHub's post and the repository advisory are the primaries here. Help Net Security, published at 14:26 UTC on 11 November 2026, is a secondary: it pointed to the primaries and adds nothing they do not print.

The headline fact is the version list. The first fixed release on each branch is 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1 and 2.56.1. The project's notes do not print an affected range. The repository advisory for the recursive clone flaw says "all" for affected versions and "none" for patched versions, which disagrees with the release (see the section on differences).

The recursive clone flaw, step by step as stated

CVE-2026-111760 is the one the story turns on. GitHub's post says Git checks paths before writing files into a working tree, including rejecting paths that would overwrite its own repository metadata, but that an integer truncation in the index handling can let an extremely long path pass validation under one name and be written under a shorter name. An attacker can use that to replace a submodule's .git file with a symbolic link to a directory holding malicious configuration or hooks, and Git then "can execute attacker-controlled code during a recursive clone".

Zoom

The advisory page is shorter than GitHub's post. It says the attacker's repository is "hosted by the attacker rather than on a normal forge site" and, on the trigger, "We currently believe this can only be triggered when the --recurse-submodules option is used." The word "currently" is the project's. The release notes describe the outcome (a gitfile overwritten by a symbolic link) and do not use the word truncation: the mechanism appears in GitHub's post, not in the notes or the advisory.

Not stated anywhere read: how long the path must be, which platforms or file systems are affected, whether Git on Windows, macOS or Linux differs, and the patch itself. The advisory says "Patches are being discussed on the git-security mailing list." That mailing list was not read, and no commit id for the fix is printed in the pages saved. GitHub's post says the fix "rejects extremely long index entry paths before their lengths can be truncated", and the release notes list a separate line, "Defense-in-depth: read-cache: reject cache entries with over-long names." Whether that line is this fix is not stated.

All six, by what triggers them

The other five need other triggers: a clone over protocol v2 from a hostile server, a merge of a crafted tag, a merge of very large conflicting output, a crafted binary patch and a fast-import stream. The table gives each as GitHub's post and the release notes print it.

Zoom

Two of the six name hosting services in their own text. For CVE-2026-114467 the release notes say a denial of service "can potentially also affect forges when such a tag is pushed to a remote and a merge action is initiated". For CVE-2026-105437 the GitLab work item says a server is exposed "when it reads attributes from trees in the repository", and adds a statement about its own product: "On GitLab this has been extended to RCE through the Git process Gitaly starts for mergeability checks." GitLab sells hosting and also assigned the CVE as its numbering authority, so that sentence is a vendor statement about its own service and was not checked.

Severity: one advisory, one CVE record, four unscored

Severity is the thinnest part of the record at the time of reading. Only two of the six ids carry a score on any page read, and they come from different places. The GitLab work items print no score at all. NVD, asked at 16:09 UTC, held no record for CVE-2026-111760 (zero results) and listed CVE-2026-105437 as Received, with GitLab's score typed Secondary.

The two scores differ in privileges required (low against none) and scope (changed against unchanged), and they describe different flaws, so they are not comparable. The record for CVE-2026-105437 also carries a reference tagged "exploit" among its tags. That tag sits on the reference to a bug bounty report, beside the tags technical-description and permissions-required; the record does not say what it means beyond that, it does not state that the flaw has been used, and the report was not opened.

What the Git project and GitHub state, and what they do not

Where the sources differ

Five differences, none resolved here.

The release date. GitHub's post, dated 10 November 2026, says the project is releasing the versions "today". The GitHub tag page for v2.56.1 prints that the tag was made on 26 October at 17:48 UTC, which is 15 days earlier (derived), and the git-scm.com home page prints 2.56.1 with the date 2026-10-26. None of the pages says why the dates differ, so this briefing does not say when 2.56.1 first became public.

Affected and patched. The advisory page for CVE-2026-111760 prints "Affected versions all" and "Patched versions none" and says patches are under discussion, while the release notes and GitHub's post, both dated or read the same day, list seven fixed releases. The advisory page was read between 16:06 and 16:20 UTC; whether it has been updated since is not known.

What the fast-import features do. GitHub's post says two of them can read arbitrary files and the third, export-pack-edges, can create files or append data. The release notes say all three "allow reading from arbitrary paths". The GitLab work item title says data "can be read or written" through fast-import and fast-export features. The article follows the post for the write capability and records the notes' narrower wording.

What counts as the fix for CVE-2026-111760. GitHub's post says the fix rejects extremely long index entry paths. The release notes list the line "Defense-in-depth: read-cache: reject cache entries with over-long names" separately from the six CVE entries. Both may describe the same change; the pages do not say.

Affected range of CVE-2026-105437. The CVE record lists version 0 up to below 2.49.1, then each branch from its first release candidate up to the fixed version. A list of released fixed versions that skips every series before 2.50 sits beside a record that marks older code affected: whether anything older than 2.50.2 is patched or only affected is not stated by any page read.

What hosting services, CI and desktops are told

GitHub sells hosted repositories, Actions and Codespaces, so its post is also a statement about its own products and the patch status it reports was not checked. It says it has deployed fixes across github.com, GitHub Enterprise Cloud and GitHub Enterprise Cloud with data residency, and that Enterprise Server fixes are in versions 3.19.15, 3.20.11, 3.21.9 and 3.22.4, with administrators advised to upgrade "as soon as possible". It is coordinating releases of GitHub Desktop and the GitHub Copilot app that carry a patched Git, and says Codespaces and Actions "will also receive patched versions of Git". No date is printed for any of these.

The project's wording for operators is general: administrators "should also update Git installations used by automation and services that process repositories on behalf of users", and everyone should update "any applications that bundle Git". For servers that run merges, the GitLab work item and the CVE record add a workaround for CVE-2026-105437 (the override in the Technical details section), or turning off server side mergeability checks for untrusted repositories.

What to do, in order

Technical details

Every block below is copied from a page read on 11 November 2026 and attributed in words. None of the pages prints an exploit, a proof of concept, a crafted path or a hook, and none is reproduced here. One block quotes a path pattern that the release notes print to show what a hostile HEAD looks like, so that a defender knows what to search for.

The ids. The sentence in the Git v2.50.2 release notes that lists the six CVE ids. The other six notes carry the same ids in a merge up sentence. A defender uses it to match scanner output to the release.

This addresses the security issues CVE-2026-111760, CVE-2026-113408,
CVE-2026-114466, CVE-2026-114467, CVE-2026-114469 and CVE-2026-105437.

The advisory fields for CVE-2026-111760. The page prints these as separate labelled fields; they are copied one per line. The vector is the CVSS 3.1 string shown on the page; the page does not say who scored it. The affected and patched fields disagree with the release.

Affected versions
all
Patched versions
none
Patches are being discussed on the git-security mailing list.
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H

The project's belief about the trigger. The only workaround the advisory prints, with the project's own hedge.

We currently believe this can only be triggered when the --recurse-submodules option is used.

The hostile HEAD pattern for CVE-2026-113408. The GitLab work item prints this example of an unborn HEAD with path traversal characters. A defender looks for symbolic reference targets that contain parent directory components in repositories fetched over protocol v2. The same item lists the workaround as TBD.

It is possible for a server to advertise an unborn `HEAD` that contains
path-traversal characters (e.g., `refs/heads/../../../TARGET`). With the files
ref backend that can lead to ref-updating actions to write to unwanted files.

The workaround for CVE-2026-114467. The work item prints one sentence and it ends where shown; the saved page contains no more.

Avoid running git-merge(1) using signed tags. Or run git-fsck(1) to verify if

The server workaround for CVE-2026-105437. One line to add to each repository's info/attributes, which takes precedence over a conflict-marker-size attribute committed in the tree. A server operator adds it to repositories that accept untrusted pushes until Git is upgraded; clients can add the same line to .git/info/attributes.

* conflict-marker-size=7

The fast-import rule for CVE-2026-114466. The behaviour after the fix and the option that turns the protection off. A defender searches scripts and tooling for the option and removes it unless the program writing the stream is trusted.

These features are now rejected when supplied through the input stream unless the caller explicitly enables --allow-unsafe-features. Only enable that option when you trust the program generating the stream.

The CVE record for CVE-2026-105437. The only record of the six ids that exists at the time of reading. The first two lines are fields of the record; the third is its solution text.

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
baseScore 7.5, baseSeverity HIGH, CWE-122, assigner GitLab
Upgrade to versions 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1, 2.56.1 or above.

What CVE.org answered for the other five. This is the exact reply for each of CVE-2026-111760, CVE-2026-113408, CVE-2026-114466, CVE-2026-114467 and CVE-2026-114469 at 16:14 UTC. A defender checks again, because scanners that rely on the CVE feed will not flag these ids until a record exists.

{"error":"CVE_RECORD_DNE","message":"The cve record for the cve id does not exist."}

The tag. The v2.56.1 tag page prints a short commit id and a tag time. The commit id is the only commit identifier printed on any page read; it identifies the release tag, not a fix.

03b4152
tagged this
26 Oct 17:48

The question the notes leave open

Seven releases and six ids tell an administrator what to install. They do not tell anyone how many machines cloned a hostile repository before 10 November, or what a clone that ran hooks would have left behind, and no page says anyone looked. Which Git version cloned the last third party repository on your build agents, and where is that written down?

Key facts