Git corrects CVE-2026-111760 that allows code execution in submodules during cloning

This week the Git project published a correction for serious vulnerability (CVE-2026-111760) that allows a malicious repository to cause the execution of code in the machine that clone it recursively along with its submodules. The problem was solved in Git 2.56.1, and matching patches were published for the branches 2.50 to 2.55. The corrections prevent excessively long file routes from passing through security controls and then are cut off when writing on disk with a name that an attacker may force to be .git, which opens the door to the replacement of the .git file of a submodule by a symbolic link to a location controlled by the attacker. Once there, Git can read hooks or configuration files from that location and run arbitrary code at times controlled by the normal Git flow.

What happened (confirmed facts): the Git project knows of an entire truncation failure in the management of the index that allows an extremely long route that should be blocked by the security checks, pass and then it is written with a shorter name. That difference between the check and the writing allows the resulting name to be exactly ".git." Since Git treats a .git directory and a .git file differently within a newly cloned submodule, an attacker can use that behavior to leave a .git file that is actually a symbolic link to an attacking folder containing hooks or other executable files. Git runs hooks at specific points (e.g. post-check, pre-commit, etc.), so the activation of those hooks from a location controlled by the attacker is the route for remote code execution. The correction given rejects such long routes before there is a possibility that the name is truncated and can become .gitto. These corrections are available in Git's release note 2.56.1: https: / / github.com / git / git / releases / tag / v2.56.1.

How it works technically (explanation): vulnerability is a condition of truncation of integers in logic that validates and writes entries in the Git index. During a recursive cloning operation with submodules, Git performs safety checks on the routes it receives from the remote repository. If a route exceeds a certain size, it should be invalidated. However, in this case the check is done with a value that is later reduced (by truncation) when Git decides how to create the file on disk. A long name can, after being truncated, match .git. In newly created submodules, .git is not a standard directory but a file that indicates the location of the Git object; that file can be replaced by a symbolic link because Git does not expect a link in a newly cloned submodule. If the link points to a folder with malicious hooks or configuration files, later normal Git operations can run that code or read settings that change the customer's behavior.

Who is affected and what is the real risk (confirmed vs estimated): equipment and services using pre-corrected Git versions and performing recursive cloning operations of non-fully reliable repositories are affected. Git client users packed by third applications (IDE, graphic customers, Git copys inside apps) are potentially at risk if these applications do not update the integrated copy. GitHub has applied the corrections to its public infrastructure and to GitHub Enterprise Cloud, and has reported that versions of GitHub Enterprise Server and some GitHub applications will receive or have already received updates; however, Git maintainers for Windows and other distributions took time to publish binaries based on 2.56.1 at the time of the initial announcement. This means that, until each distributed platform or package updates your Git copy, the risk persists for those who are unable or unwilling to update.

It is important to stress what is not publicly confirmed: there is no clear reference in the official notes to active exploitation in nature (there have been no widely verified public samples or forensic reports at the time of the patch). Given the vector - repositories that are cloned recursively - and the ease to embed submodules, the risk of abuse is high in theory, especially against developers and servers that automate clones and third-party projects. Services that run merges or checks on behalf of users (for example, checks on continuous integration servers or hosts that run code operations provided by users) are groups that, according to GitLab, can be preferred targets for exploits focused on the git merge-tree command.

Other corrections including: In addition to the CVE-2026-111760, the last round of patches fixes several failures with potential for memory corruption, off-limits reading and abuse of fast import functions. Among them are vulnerabilities that allow for writing outside the reference tree after an empty clone by protocol v2, corrupt labels with multiple GPG signatures, binary patches that exceed the limit and cause off-limits readings, over-writing of buffer in very large merges with modified conflict- marker- size attributes and the possibility of reading or creating arbitrary files by certain features of git fast-import; the latter are now blocked unless they are explicitly invoked --allow-unsafe-features. The additional technical details and mitigation were documented by the Git project and by accommodation teams such as GitHub and GitLab.

What should the reader do now (concrete actions): first, check the Git version on the machines you administer running Git locally (e.g. with git --version). If you use a version before 2.56.1 or the parched versions of the 2.50-2.55 branches, update as soon as possible from the official source or package manager of your system. If your organization uses GitHub Enterprise Server instances, check the version notes for the parched versions (the corporate versions that have already received the corrections are listed by GitHub) and apply the platform updates according to the maintenance schedule. Also, if you use applications that include your own copy of Git (desktop customers, IDes, containers or third party apps), ask or check with the supplier when they will enter the corrected version and apply your updates. GitHub also publishes provisional recommendations: clone only from origins that you trust and avoid the use of recursive cloning in unverified repositories; do not mix content or labels from unreliable sources; and do not process binary patches or fast-import flows from unreliable sources. For more details on the Git update see the official documentation: https: / / docs.github.com / en / get-started / using-git / updating-git. To understand how the hooks that can be abused operate, Git's official documentation on hooks is useful: https: / / git-scm.com / docs / githouks.

As an additional measure for server administrators who are not yet able to update, GitLab and others have suggested temporary mitigation for specific failures (for example, setting conflict-marker-size in info / attributes of the repositories or disable checks of merge@-@ tree for unreliable repos). These specific measures correspond to certain vulnerabilities between those corrected and are applicable in contexts where immediate updating is not possible.

Abstract: vulnerability exposes a practical vector to run code contained in malicious submodules during recursive cloning. The official solution is already published; the immediate responsibility is to update the copies of Git distributed in own systems and services, and to avoid automated operations on repositories of dubious origin until all parts of the ecosystem (operating systems, customers and services) incorporate the correction.