Git 2.56.1 patches six vulnerabilities, and your CI runners need it more than your laptop does

On November 10, the Git project shipped Git 2.56.1, plus patched releases for older maintenance lines: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 and 2.50.2. Between them they close six CVEs: CVE-2026-111760, CVE-2026-113408, CVE-2026-114467, CVE-2026-114469, CVE-2026-105437 and CVE-2026-114466. The project calls this a set of coordinated security fix releases and wants people to update at their earliest convenience. Luke Martin and pwn2addr found the bugs.

The one to care about is CVE-2026-111760, rated High at CVSS 8.0 in the project's security advisory. The short version: Git's index code has an integer truncation bug. A very long path gets checked under its full name, then lands on disk under a shorter one. An attacker can use that mismatch to replace a submodule's .git file with a symlink pointing at a directory they control, stuffed with their own config or hooks. Hooks are code. So a recursive clone of the wrong repository can end with someone else's code running on your machine. The advisory says it's believed to be reachable only when you pass --recurse-submodules.

GitHub has already patched github.com, GitHub Enterprise Cloud and Enterprise Cloud with data residency. If you run GitHub Enterprise Server yourself, the fixed versions are 3.19.15, 3.20.11, 3.21.9 and 3.22.4.

The score undersells this for most teams

Read the CVSS vector and you might relax a bit. High attack complexity, low privileges, user interaction required. On a developer laptop that's fair: someone has to recursively clone a hostile repo.

But think about who actually runs git clone in your organisation. Mostly it's not people. It's CI runners, hundreds of times a day, with nobody watching and with deploy keys and cloud credentials sitting in environment variables. "User interaction required" doesn't mean much when the user is a YAML file.

When we build cloud-native apps for enterprise clients, the Git that matters is rarely the one on anyone's laptop. It's the one baked into a Docker base image somebody chose a year and a half ago, the one on a self-hosted runner, the one inside a deploy container. Running a package update on your Mac touches none of those. From our PHP and Docker work, my honest guess is that most teams have three or four different Git versions on their build and deploy paths and couldn't list them without going to look.

Mobile teams have their own version of this. In our native iOS and Android projects, submodules are still a common way to pull in shared SDKs, vendored native libraries or an internal UI kit. The build machines are often long-lived Macs that nobody has reimaged in ages. And the Git project specifically tells you to update any application that bundles its own copy of Git, which covers a fair number of IDEs and desktop clients. Updating the system Git doesn't fix those.

On the security side, this fits a pattern we keep running into. During our pentesting engagements, the build pipeline is regularly the easiest way in, because it trusts things nobody would let near production: a contractor's fork, a vendor's sample project, an open-source dependency pulled in as a submodule. People forget hooks are executable. Attackers don't.

I'll admit some mixed feelings. Six CVEs in one go, in a tool this old and this trusted, is a bit unnerving. At the same time, coordinated fixes across seven release lines is exactly the dull, competent maintenance you want from a project everyone depends on. The fix is out. The hard part is on our side: finding every copy.

What I'd do this week

1. Inventory every Git binary, not just laptops. Run git --version inside your CI images, Dockerfiles, self-hosted runners and build Macs. You want 2.56.1, or the patched release for your series (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 or 2.50.2).
2. Rebuild base images on purpose. Don't assume the next scheduled rebuild picks up a fixed Git. Check the version in the built image.
3. If you self-host GitHub Enterprise Server, get onto 3.19.15, 3.20.11, 3.21.9 or 3.22.4.
4. Search your pipeline config for recursive submodule checkouts. Where the parent repo or any submodule isn't fully under your control, turn recursion off until the runner is patched.
5. Until everything is updated, follow the project's interim guidance: only clone from servers you trust, skip recursive clones of anything untrusted, and be careful merging outside content or tags, applying binary patches, or feeding fast-import streams from sources you don't control.

For our Swiss clients with compliance requirements, I'd add a sixth step: write down what you patched and when. Auditors like evidence, and for a patch this widespread you'll want it ready rather than reconstructed later. We cover this kind of pipeline hygiene when we set up build and deploy infrastructure, and it comes up constantly in our security reviews.

If you aren't sure how many copies of Git are hiding in your build pipeline, let's talk.