The Git project released security patches this week addressing six vulnerabilities that range from arbitrary code execution to memory corruption. If you’re using Git in any capacity, this matters to you. Let me walk through what’s happening and why you should care.
The Vulnerabilities Hitting Git
The fixes are bundled into Git 2.56.1, with backports available for older maintenance branches going back to 2.50.2. Six separate issues were patched, and they’re not trivial.
The most concerning involves recursive clones of malicious repositories. Git validates paths before writing files to prevent overwriting repository metadata, but an integer truncation bug in index handling can cause extremely long paths to pass validation under one name and then get written using a shorter name. An attacker exploits this discrepancy by replacing a submodule’s .git file with a symlink pointing to a directory containing malicious hooks. When Git processes that recursive clone, it executes attacker-controlled code.
Then there’s the issue with Git protocol v2. When cloning empty repositories, the server advertises a HEAD symref pointing to an unborn branch. Git wasn’t validating this target before storing it locally. A malicious server could supply path-traversal components that later write references outside intended directories.
Binary patches present another problem. Git rejects patches larger than roughly 1 GiB, but this check only considered the supplied size. Since binary patches are compressed, a relatively small patch can expand beyond the limit and bypass validation entirely, causing out-of-bounds reads that crash Git.
Memory corruption also occurs when stripping GPG signatures. Git assumed at most two signatures in a message, using a fixed-size stack array. A specially crafted message with more than two signatures causes writes past the array boundary, potentially triggering denial of service.
Merge operations have their own overflow vulnerability. Git calculates memory needs before writing output, but this calculation overflows with very large results, especially when combining many conflicts with large conflict-marker-size attributes. The resulting buffer allocation is too small, leading to heap corruption.
Finally, git fast-import had insufficient protections. The rewrite-submodules-from and rewrite-submodules-to features could read arbitrary files and expose contents through error messages. The export-pack-edges option could create files or append to existing ones. These now require explicit —allow-unsafe-features flags.
What This Means for You
I want to be direct: if you’re running older Git versions, your systems are vulnerable. The scope here covers local development, CI/CD pipelines, hosting services, and any application bundling Git.
For individual developers, the risk profile depends on your workflow. If you clone only from trusted repositories and avoid recursive clones of untrusted code, your immediate risk is lower. But if you’re in an environment where you merge pull requests from unknown contributors or process binary patches, you’re exposed.
For teams operating DevSecOps practices, this is exactly the kind of vulnerability where shifting security left matters. I’d argue this connects directly to the importance of understanding your dependency chain. Git isn’t optional infrastructure; it’s foundational. You need visibility into which versions your organization runs and how to deploy patches systematically.
For DevOps engineers and platform teams, this is urgent. If your CI/CD agents use Git to fetch and process repositories from any untrusted source, you need updates deployed immediately. Hosting services are particularly at risk because they perform merges on behalf of users.
Immediate Actions
Update to Git 2.56.1 or the appropriate patched release for your maintenance series. If you’re on an older branch, patches are available for 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, and 2.50.2.
If you can’t update immediately, implement mitigations. Clone only from trusted servers and avoid recursive clones of untrusted repositories. Don’t merge untrusted content or process binary patches from unknown sources. These precautions don’t replace fixes, but they reduce your attack surface.
For teams managing infrastructure, audit your Git installations across development machines, CI/CD systems, and automation services. Update applications that bundle their own Git copies. This sounds straightforward but often gets missed because teams don’t think of Git as a separately updatable component.
I think what’s important here isn’t just the specific vulnerabilities, but recognizing that even foundational tools need security attention. These bugs existed in Git for years before discovery. That’s not a failure of the Git project; it’s reality. What matters is how quickly the community patches issues and how seriously we take updates.