HudHud Tech — Tech & AI news platform
Wednesday, 11 November 2026
Breaking
Software & Apps | Cybersecurity

Git 2.56.1 addresses six security vulnerabilities

11 November 2026 5 min read هدهد تك | Hudhud Tech

The Git project released new versions on November 10, 2026, to fix six security vulnerabilities. The flaws include arbitrary code execution when recursively cloning a malicious repository, writes to unintended files, and memory corruption when processing merges or binary patches.

The fixes ship in Git 2.56.1, with backports to Git 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, and 2.50.2. The project recommends updating to Git 2.56.1 or the patched release for your maintenance series, and updating any applications that bundle Git.

Code execution during recursive clones

Git checks paths before writing files into a working tree, including rejecting paths that would overwrite its own repository metadata. However, an integer truncation in Git’s index handling can let an extremely long path pass validation under one name and then be written using a shorter name.

An attacker can use this discrepancy to replace a submodule’s .git file with a symbolic link pointing to a directory containing malicious configuration or hooks. When Git later uses that directory, it can execute attacker-controlled code during a recursive clone. The fix rejects extremely long index entry paths before their lengths can be truncated.

Path traversal through an advertised HEAD

When cloning an empty repository using Git protocol v2, the server can advertise a HEAD symref pointing to an unborn branch, one with no commits yet. Git did not validate the symref’s target before storing it locally.

A malicious server can supply a name containing path-traversal components. With the files reference backend, a later operation that updates the branch can write outside the intended reference directory. Git now validates the advertised target before accepting it, and the release also validates other reference names and symbolic-reference targets received through protocol v2.

Memory corruption in signatures, patches and merges

When stripping GPG signatures from a message, Git assumed there would be at most two signatures. A crafted message with more than two can make Git write past the end of a fixed-size stack array. Merging a tag containing more than two signatures can trigger this, causing memory corruption and a potential denial of service, and hosting services that perform such merges for users can also be affected. The fix removes the fixed-size array and handles messages with any number of signatures.

Git rejects patches larger than approximately 1 GiB because its patch application code cannot safely handle larger inputs, but that check only considered the size of the patch as supplied. Binary patches are compressed and encoded, so a relatively small patch can expand beyond that limit. A crafted patch can bypass the input-size check and cause an out-of-bounds read, crashing Git. Git now also checks the declared uncompressed size before processing a binary patch.

Git’s merge machinery calculates how much memory it needs for a merge result before writing the output. That calculation can overflow when the result is very large, including when many conflicts are combined with a large conflict-marker-size attribute. The overflow can make Git allocate a buffer that is too small and then write outside it, corrupting heap memory. This affects applications and hosting services that merge untrusted content, as well as local merges. The fix uses size-appropriate types and checked arithmetic, rejecting merges whose output size cannot be represented safely.

Filesystem access through fast-import

git fast-import reads a stream of commands to build a repository. Some commands can access files outside the repository, so Git already restricts them when they appear in an untrusted input stream. Three additional features lacked that protection.

The rewrite-submodules-from and rewrite-submodules-to features can read arbitrary files, potentially exposing their contents through error messages. The export-pack-edges option can create files or append data to existing files. These features are now rejected when supplied through the input stream unless the caller explicitly enables --allow-unsafe-features, which should only be enabled when the program generating the stream is trusted.

Hardening and GitHub updates

Alongside these fixes, the release adds overflow checks to related index entry allocations during checkout and tree processing. These complement the path-length limits, preventing allocation sizes from being truncated or overflowing before Git copies a path into memory.

GitHub says it has deployed fixes across github.com, GitHub Enterprise Cloud, and GitHub Enterprise Cloud with data residency. Updates for GitHub Enterprise Server are available in versions 3.19.15, 3.20.11, 3.21.9, and 3.22.4, and administrators are advised to upgrade as soon as possible.

GitHub is coordinating releases of GitHub Desktop and the GitHub Copilot app that include patched versions of Git. GitHub Codespaces and GitHub Actions will also receive patched versions.

Updating is the most effective protection. Install a patched version from your operating system or Git distributor, and update applications that include their own copy of Git. Administrators should also update Git installations used by automation and services that process repositories on behalf of users.

If an immediate update is not possible, clone only from trusted servers and avoid recursive clones of untrusted repositories. Avoid merging untrusted content or tags, and processing binary patches or fast-import streams from untrusted sources. These precautions do not replace installing the fixes.

 

Source: GitHub Blog

What do you think of this story?

Share this story: