Git has six new security fixes. Here's who needs to update, and what to do until your server can
Git released fixes for six security flaws yesterday. The worst one can run an attacker's code on your machine when you clone a booby-trapped repository with its submodules.
Most small business servers that just pull their own code aren't in the firing line. Developer laptops, build servers and anything that hosts Git repositories for other people are. And as I write this, the big Linux distributions haven't shipped fixed packages yet, so there's a gap to manage.
What happened
GitHub's write-up of the release, published on 10 November, covers six flaws "affecting recursive clones, reference handling, merges, binary patches, and imports". The fixes are in Git 2.56.1, with backports to 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 and 2.50.2.
The one that matters most is CVE-2026-111760. A crafted repository can swap a submodule's .git file for a link to a folder containing the attacker's own settings and hooks. Git then runs that code during a recursive clone. Red Hat rates it Important, with a score of 8.8 out of 10.
The other five are less dramatic. A malicious server can make Git write files where it shouldn't when you clone an empty repository from it. Crafted tags, binary patches and very large merges can corrupt memory or crash Git. And git fast-import would accept some risky options from an untrusted stream.
I haven't seen any reports of these being used in attacks. That's a good reason to deal with it calmly this week rather than tonight.
Does it affect you?
Almost every one of these needs Git to handle something from a source you don't control: a stranger's repository, a malicious server, an untrusted tag or patch. So the question is where your machines do that.
Developer laptops. These are the most exposed. Developers clone other people's code all the time, often with submodules. If someone builds or looks after your software, ask them to update Git on their own machine first.
Build and deployment servers. If a build server or deploy script clones third-party repositories, especially with --recurse-submodules or --recursive, it's in scope.
Self-hosted Git. If you run your own GitHub Enterprise Server, GitLab or Gitea, the server is doing merges and handling pushes for users. GitHub says Enterprise Server fixes are in 3.19.15, 3.20.11, 3.21.9 and 3.22.4, and recommends upgrading "as soon as possible". For the others, watch for a release from the vendor that includes the new Git.
A web server that pulls its own code. If your site's server only ever does git pull from your own repository on GitHub, GitLab or Bitbucket, the risk is much lower. GitHub says the fixes are already deployed on github.com. You still want the update, just not at midnight.
The catch: your Linux packages aren't fixed yet
This is where it gets a bit awkward. The Git project has done its part, but most servers get Git from their distribution, not from git-scm.com.
When I checked this morning, Debian's security tracker listed all six flaws as still open in Debian 12 and 13. I couldn't find a fixed package from Ubuntu or Red Hat yet either. They will come, usually as a backport, so the version number you see won't jump to 2.56.1. Don't panic when it doesn't.
What to do this week
1. Update the laptops now. The official download page already lists 2.56.1. Update from there, or through whatever installed Git in the first place (Homebrew on a Mac, for example). Check with:
git --versionRemember that some apps, such as GitHub Desktop, bundle their own copy of Git. GitHub says a patched Desktop is on its way, so update those apps too.
2. Find your recursive clones. On build and deploy servers, search your scripts for the risky options:
grep -rnE "recurse-submodules|--recursive" /path/to/your/scriptsAnything that clones a repository you don't own with one of those flags is worth pausing or pointing at a copy you control until the server is patched.
3. Follow GitHub's interim advice. Until you can update, the advice is to "clone only from trusted servers and avoid recursive clones of untrusted repositories", and to avoid merging untrusted content or tags. GitHub is clear that this doesn't replace the fix.
4. Patch servers when the packages land. Keep an eye on your distribution's security notices and run the normal update when the fix appears:
sudo apt update && sudo apt upgradeOn Ubuntu and Debian, apt changelog git should show you the CVE numbers once the fixed package is in.
5. Upgrade self-hosted Git servers. If you run GitHub Enterprise Server, GitLab or Gitea, take a backup and book the upgrade in for this week.
The bigger point
Git is so dependable that nobody thinks about it, and it rarely makes anyone's update list. This week it should.
If your code is looked after by a developer who's since moved on, and you're not sure what clones what, or where, the team at Dev Partners have a first-week checklist for exactly that situation. They also take on existing software and keep it updated month to month.
For the servers themselves, this is what a support retainer is for. I watch for the fixed packages, install them, check nothing's broken and tell you in plain English what changed.
Liked that? Get the next one by email
When a security flaw lands that could affect your server, I'll email you what it means and what to do. Plus the odd opinion piece. Not often, no spam.