Newshot
Account

Git patches high-severity code execution flaw triggered by recursive cloning of malicious repos

AI summary

The core vulnerability is an integer truncation issue that can lead to code execution in submodule scenarios. Git has a high-severity code execution vulnerability that can be triggered if a user recursively clones a malicious repository containing submodules.

Translation(model translation, not the source's own text)

Article title: Git Patches High-Severity Code Execution Flaw Triggered by Recursive Cloning of Malicious Repositories

Body:

image
image

Core Flaw Is an Integer Truncation Issue, Code Execution Can Be Triggered in Submodule Scenarios

Git contains a high-severity code execution vulnerability: if a user recursively clones a malicious repository containing submodules, an attacker can execute arbitrary code on the user's device. The Git project fixed the flaw this week in version 2.56.1 and also pushed corresponding patches to the 2.50 through 2.55 release series, covering versions such as 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, and 2.55.1.

The vulnerability is tracked as CVE-2026-111760 and stems from an integer truncation issue in Git's handling of the index. An overly long path in a repository can bypass Git's security checks; when Git later writes the path to disk, it is truncated to a shorter filename, and an attacker can set the truncated filename to .git.

Using this issue, an attacker can replace a submodule's .git file with a symbolic link pointing to a folder containing malicious hooks or malicious configuration. Hooks are programs Git runs automatically at specific operation points; once Git invokes the contents of that folder, the attacker's implanted code executes.

Submodules are the key condition for triggering the vulnerability. Git itself does not allow the .git folder to be replaced with a symbolic link, but in a newly cloned submodule, .git is a file rather than a folder, so it can be replaced. The fixed versions block such overly long paths directly before the path length is truncated, cutting off the attack path at its root.

Fixes Pushed Across Multiple Platforms, Temporary Protections Available for Users Who Have Not Upgraded

GitHub embeds Git components in several of its tools, and the company has published a detailed advisory explaining the fix, recommending that users install the fixed versions through their operating system or Git distribution channel and also update all applications that bundle copies of Git.

GitHub has currently deployed the fix for github.com and GitHub Enterprise Cloud. The GitHub Enterprise Server fix covers versions 3.19.15, 3.20.11, 3.21.9, and 3.22.4. Fixed versions for GitHub Desktop and GitHub Copilot are in preparation, and GitHub Codespaces and GitHub Actions will also be updated with the bundled fixed Git.

According to The Hacker News' check of Git for Windows release tag information, as of 19:09 UTC on Tuesday, the project had not yet released a fixed version based on Git 2.56.1.

Before installing the official fixed version, GitHub offered the following temporary mitigations; note that these measures cannot replace the official patch:

  • Clone repositories only from trusted servers
  • Do not recursively clone repositories of untrusted origin
  • Do not merge untrusted content or tags
  • Do not process binary patches or fast-import streams from untrusted sources

Five Vulnerabilities Fixed in the Same Batch, Hosting Platforms Face Specific Attack Risk

This Git release also fixes five other security vulnerabilities, covering risk types such as path traversal, denial of service, out-of-bounds read/write, and arbitrary file access.

  • CVE-2026-113408: When a user clones an empty repository via Git protocol v2, a malicious server can send a branch name containing path traversal characteristics. If the files reference backend is used, subsequent updates to that branch can write files outside the Git references folder.
  • CVE-2026-114467: Merging a tag carrying more than two GPG signatures corrupts Git's stack memory, which can cause denial of service; code hosting platforms that provide merge services to users may also be affected.
  • CVE-2026-114469: A binary patch that is extremely large after decompression can bypass Git's roughly 1GiB patch size limit, triggering an out-of-bounds read that crashes Git.
  • CVE-2026-105437: If a merge operation is extremely large, contains many conflicts, and has a large conflict-marker-size attribute set, Git writes out-of-bounds data into an undersized buffer, corrupting heap memory.
  • CVE-2026-114466: Three git fast-import features—rewrite-submodules-from, rewrite-submodules-to, and export-pack-edges—can be exploited to read arbitrary files or create files and write data. Git now rejects such directives in input streams by default unless the user explicitly sets the --allow-unsafe-features parameter.

CVE-2026-105437 was assigned by GitLab. GitLab said code hosting servers are most likely to be attacked through this vulnerability via the git merge-tree feature, which servers typically run to check whether a pull request or merge request can be merged cleanly. An attacker can set the conflict-marker-size attribute in a .gitattributes file committed to the repository; if the server reads the attribute configuration directly from the repository, any user with permission to push a branch and open a pull or merge request can trigger the vulnerability.

Servers that cannot upgrade for the time being can take temporary mitigations: add the conflict-marker-size=7 setting to each repository's info/attributes file, or disable such merge checks for untrusted repositories.

Git Patches Flaw That Lets Malicious Repositories Execute Code During Recursive Clones

The translation is machine-generated and individual terms may be off. Nothing is rewritten or cut; the original is authoritative.

Published by FreeBuf
This site only summarises and aggregates; copyright stays with the original author. Headlines and summaries follow the source — where they differ, the original wins.
Read the original ↗