# Git 2.56.1 Fixes 6 CVEs, One a Clone RCE. Patch CI, GitLab 19.5.4 and GHES

URL: https://www.devopsness.com/blog/git-2-56-1-six-cves-recursive-clone-rce-gitlab-19-5-4
Author: Kiril Urbonas
Published: 2026-11-11
Updated: 2026-11-11
Categories: DevOps
Tags: Git, Security, CVE, CI/CD, News

Summary: Git 2.56.1 and six backports fix six CVEs, including code execution during recursive clones and a merge heap overflow that GitLab rates Critical inside Gitaly. The git on your runners, images, forge and laptops updates through different channels. Checks for each one, fixed versions and stopgaps.

---
# Git 2.56.1 Fixes 6 CVEs, One a Clone RCE. Patch CI, GitLab 19.5.4 and GHES

Git 2.56.1 shipped on November 10, 2026 with fixes for six CVEs, including code execution during a recursive clone. Patch every git you run: CI runners and container images first, then self-managed GitLab (19.5.4, 19.4.6 or 19.3.8) and GitHub Enterprise Server. Until then, stop recursive clones of untrusted repositories.

> [!VERIFIED]
> Git 2.56.1 and the 2.50.2 to 2.55.1 backports, GitLab 19.5.4, 19.4.6 and 19.3.8, GHES 3.19.15, 3.20.11, 3.21.9 and 3.22.4, against the GitHub Blog announcement, the git/git advisory GHSA-vp2w-7xxj-jvxr, the CVE-2026-105437 record, the GitLab patch release notes, the GHES 3.22 release notes, the Git for Windows 2.56.1 release and the Debian security tracker. Checked November 11, 2026.

## What happened, in dates

- **November 10, 2026:** Git 2.56.1 and six backport releases ship. GitHub patches github.com and releases fixed GHES versions; GitLab ships 19.5.4, 19.4.6 and 19.3.8 with a patched bundled git; Git for Windows 2.56.1.windows.1 follows.
- **As of November 11:** the Debian security tracker lists git in bookworm, trixie, forky and sid as vulnerable, with no fixed version yet.

## Six CVEs, ranked by who should move first

| CVE | What triggers it | Who is exposed | Priority |
|---|---|---|---|
| CVE-2026-111760 | Recursive clone of a crafted repository; a submodule's `.git` file is replaced by a symlink to attacker config or hooks | CI jobs and developers running `clone --recurse-submodules` on repos they do not control | 1 |
| CVE-2026-113408 | Cloning an empty repo over protocol v2 from a server that advertises a HEAD symref with path-traversal components | Anything that clones from arbitrary URLs with the files ref backend | 2 |
| CVE-2026-105437 | Three-way merge with many conflicts and a huge `conflict-marker-size` set in `.gitattributes` | Forges that run server-side merge checks (GitLab confirms Gitaly), plus anyone merging untrusted branches | 1 for forges, 2 otherwise |
| CVE-2026-114467 | Merging a tag that carries more than two GPG signatures | Forges and bots that merge pushed tags | 3 |
| CVE-2026-114469 | Applying a binary patch that inflates past Git's roughly 1 GiB limit | Tools that run `git apply` on untrusted patches | 3 |
| CVE-2026-114466 | fast-import streams using `rewrite-submodules-from`, `rewrite-submodules-to` or `export-pack-edges` | Migration and import pipelines fed by untrusted streams | 3 |

The recursive clone bug comes first because CI runners clone whatever a job names, often with credentials in reach. The path-traversal bug has no published score and no code-execution claim, so it ranks lower. The git/git advisory for CVE-2026-111760 carries a CVSS 3.1 score of 8.0 and says the crafted repository is "hosted by the attacker rather than on a normal forge site." A repository on a normal forge can still point its submodule URLs at any server, so a recursive clone of an untrusted repo is the case to stop.

For forge operators, CVE-2026-105437 is the top item. The CVE record, published by GitLab with a CVSS 3.1 score of 7.5, says `git merge-tree` is the most likely target on forges: when the server reads attributes from trees in the repository (for example through `attr.tree` or `--attr-source`), anyone who can push a branch and open a merge request can trigger the overflow. GitLab rates it Critical, says it could be used to execute arbitrary commands within the Gitaly environment, and lists all versions from 16.2 as affected.

## Am I affected?

Runners, base images, the forge and laptops each carry their own git and update on their own schedule.

```bash
# Laptops and VM runners: anything below 2.56.1 (or your line's backport) is exposed
$ git --version

# Self-managed GitLab (Linux package): GitLab version and the git Gitaly uses
$ sudo gitlab-rake gitlab:env:info | grep -iE 'version'
$ sudo -u git -- /opt/gitlab/embedded/bin/gitaly git version

# GitHub Enterprise Server, from the admin shell
$ ghe-version

# Every image running in the cluster: which git does it ship?
$ for img in $(kubectl get pods -A -o jsonpath='{..image}' | tr ' ' '\n' | sort -u); do
    printf '%s: ' "$img"
    docker run --rm --entrypoint git "$img" --version 2>/dev/null || echo "no git or no access"
  done

# Dockerfiles and CI config that install git or clone submodules recursively
$ grep -rnE 'apk add.*\bgit\b|apt-get install.*\bgit\b|dnf install.*\bgit\b' --include='Dockerfile*' .
$ grep -rnE 'recurse-submodules|submodules: *(true|recursive)|GIT_SUBMODULE_STRATEGY: *(normal|recursive)' \
    .github/ .gitlab-ci.yml 2>/dev/null
```

The loop pulls each image, so run it with registry access. Images without git print the fallback line, the good answer.

## Fixed versions, as of November 11, 2026

| Channel | Fixed in |
|---|---|
| Upstream Git | 2.56.1, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, 2.50.2 |
| Git for Windows | 2.56.1.windows.1 |
| Homebrew `git` | 2.56.1 |
| GitLab CE/EE self-managed | 19.5.4, 19.4.6, 19.3.8 |
| GitHub Enterprise Server | 3.19.15, 3.20.11, 3.21.9, 3.22.4 |
| Debian (bookworm, trixie, forky, sid) | not yet fixed |

Debian bookworm ships git 2.39.5 and trixie 2.47.3, both older than the 2.50 line, so fixes will arrive as backports under the old version number. Judge distro packages by their security tracker, not by `git --version`.

## What to do now

**Patch each channel.**

```bash
$ sudo apt-get update && sudo apt-get install --only-upgrade git   # once your distro ships the fix
$ sudo dnf upgrade git
$ apk upgrade git
$ brew upgrade git
$ winget upgrade --id Git.Git -e   # or the installer from the Git for Windows release page
```

Rebuild every image that installs git and redeploy; a restarted pod keeps its old image.

**Self-managed GitLab.** Upgrade the Linux package, Docker image or Helm chart to 19.5.4, 19.4.6 or 19.3.8. GitLab lists no new migrations, so multi-node setups should not need downtime. Self-compiled installs must follow the "Update Gitaly" steps and rebuild the git at `git.bin_path`, or upgrade a distro git to 2.56.1 or later, or to a build your distribution has patched. If you patched for the regex RCE in [CVE-2026-110264](/blog/gitlab-cve-2026-110264-regex-rce-patch-now), this is another round on the same branches.

**GHES.** Upgrade to 3.19.15, 3.20.11, 3.21.9 or 3.22.4.

**Stopgaps until every git is patched.** The GitHub Blog's guidance: clone only from trusted servers, avoid recursive clones of untrusted repositories, and do not merge untrusted content or tags or process untrusted binary patches or fast-import streams. It says these do not replace the fixes.

```bash
# actions/checkout defaults to submodules: false. Keep it that way for fork PRs.
# GitLab CI: set this on jobs that build untrusted code
#   variables:
#     GIT_SUBMODULE_STRATEGY: none

# submodule.recurse already defaults to false; pin it. fetch defaults to on-demand.
$ git config --global submodule.recurse false
$ git config --global fetch.recurseSubmodules false

# fast-import: never add --allow-unsafe-features for a stream you did not generate
```

Per the git-config docs, `git clone` ignores `submodule.recurse`, so for clones the only control is not passing `--recurse-submodules`. The config lines only stop later fetches and checkouts from recursing.

For CVE-2026-105437 on a server you cannot upgrade yet, the CVE record documents a workaround: append `* conflict-marker-size=7` to each repository's `info/attributes`, which overrides any in-tree `.gitattributes` (7 is Git's usual marker length, so only custom sizes change), or turn off server-side mergeability checks for untrusted repositories. GitLab's patch notes list no workaround and name no setting for disabling those checks, so treat this as a bridge to 19.5.4, not a substitute.

## Where this breaks

The CVE-2026-111760 advisory says it "can only be triggered" with `--recurse-submodules` as currently understood; that is a belief, not a guarantee. A separate `git submodule update --init` on the same untrusted repo fetches the same submodules, so treat it with the same suspicion. Patching the forge does nothing for the runner, and patching the runner host does nothing for the git inside the job's image; our [GitHub Actions security hardening guide](/blog/github-actions-security-hardening) covers that layering.

GitLab has released a threat detection called "Git merge-tree child process crash" for self-managed instances. As of November 11, none of the sources above says whether any of these bugs has been exploited in the wild.

## Questions people ask

### Is GitHub Actions affected by the Git 2.56.1 CVEs?

GitHub says Actions will get patched Git; check the runner image release notes for 2.56.1. The bigger exposure is your workflow: a job that runs `actions/checkout` with `submodules: true` or `recursive` on fork pull requests, or clones arbitrary URLs. Self-hosted runners and container jobs use whatever git you installed.

### Does disabling submodules stop CVE-2026-111760?

According to the git/git advisory, yes for now: the maintainers believe it can only be triggered with `--recurse-submodules`. It does nothing for CVE-2026-113408, which needs only a clone from a malicious server.

### Is GitLab.com affected by CVE-2026-105437?

No action is needed. GitLab's patch release says GitLab.com and GitLab Dedicated are already running the patched version. The upgrade is for self-managed CE and EE from 16.2 onward, to 19.5.4, 19.4.6 or 19.3.8.

## The call we'd make

Patch runners and rebuild images today, starting with any job that clones repositories you do not control, and set `GIT_SUBMODULE_STRATEGY: none` or `submodules: false` on those jobs regardless of patch state. Then schedule GitLab 19.5.4 or the GHES release this week. The caveat: Debian had not shipped fixes as of November 11, so a "fully patched" OS can still carry vulnerable git. Track the security tracker, and treat these as one more [supply chain](/blog/software-supply-chain-attacks) input you have to inventory.

## Sources

- [GitHub Blog: Git security vulnerabilities announced](https://github.blog/open-source/git/git-security-vulnerabilities-announced-7/)
- [git/git: GHSA-vp2w-7xxj-jvxr, recursive clones RCE (CVE-2026-111760)](https://github.com/git/git/security/advisories/GHSA-vp2w-7xxj-jvxr)
- [CVE.org: CVE-2026-105437 record](https://www.cve.org/CVERecord?id=CVE-2026-105437)
- [GitLab: Patch release 19.5.4, 19.4.6, 19.3.8](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-4-released/)