Global News | November 12, 2026

The Git vulnerability tracked as CVE-2026-111760 could allow attacker-controlled code to run when a user recursively clones a specially crafted repository containing submodules, according to GitHub’s security announcement.

The Git project has released Git 2.56.1 and updates for several maintenance branches to address the issue and five other security vulnerabilities. GitHub recommends updating Git and applications that bundle their own copy of it.

The recursive-clone flaw involves an integer truncation error in Git’s handling of an unusually long path. GitHub says the discrepancy can allow a malicious repository to replace a submodule’s Git metadata file with a symbolic link to attacker-controlled configuration or hooks.

The sources reviewed describe a potential attack, not a verified campaign exploiting this specific flaw. Developers and organizations should identify the Git installations they use, apply the appropriate fixes and review automated workflows that process untrusted repositories.

A Repository Can Influence the Clone Process

Git is a version-control system used to retrieve, manage and share source code. A repository can include submodules, which are references to other repositories used as part of a larger project.

A recursive clone retrieves the main repository and initializes its submodules. This can be convenient for development, but it also means Git processes additional repository content as part of the clone operation.

GitHub says CVE-2026-111760 arises because an extremely long path can pass validation under one name and then be written using a shorter name after integer truncation. Under the described conditions, an attacker can replace a submodule’s .git file with a symbolic link pointing to a directory containing malicious configuration or hooks.

Hooks are programs that Git can run at defined points in its workflow. GitHub says that when the vulnerable client subsequently uses the attacker-controlled directory, the crafted content can cause code execution during a recursive clone.

The issue should not be generalized into a claim that simply viewing any repository executes code. The described attack requires a specially crafted repository and the relevant vulnerable recursive-clone workflow.

The Security Boundary That Failed

Git checks paths before writing files into a working tree, including checks intended to prevent overwriting its own repository metadata. GitHub describes the issue as a mismatch between the name used for validation and the shorter name ultimately used when the file is written.

A symbolic link is a filesystem entry that points to another location. In the attack described by GitHub, a submodule’s .git file can be replaced with a link to a directory containing attacker-controlled configuration or hooks.

The fix rejects extremely long index-entry paths before their lengths can be truncated. GitHub says the release also adds related overflow checks to index-entry allocations used during checkout and tree processing.

The vulnerability affects the Git client’s processing of crafted repository content. It is separate from the question of whether a user intentionally runs a project’s build scripts after cloning. In the described scenario, the harmful code can run during the clone itself.

Fixed Git Releases

GitHub says fixes for the six vulnerabilities are included in Git 2.56.1, with backports for these maintenance releases:

• Git 2.55.1.
• Git 2.54.1.
• Git 2.53.1.
• Git 2.52.1.
• Git 2.51.3.
• Git 2.50.2.

Users should install the appropriate patched release for their maintenance series or a supported fixed package supplied by their operating-system or Git distributor. Distribution packages may include backported fixes under their own versioning, so administrators should consult the relevant vendor advisory rather than compare only the upstream version number.

The Git for Windows project has also published Git for Windows 2.56.1, which its release notes identify as addressing CVE-2026-111760 and the other five issues. Users should obtain updates through a trusted official or organizational distribution channel.

A machine can have more than one Git installation. A system package, development application, portable tool and build environment may each use a different copy. Updating one does not automatically establish that the others are fixed.

Five Other Issues in the Release

The November security release addresses six vulnerabilities in total. The five additional flaws have different triggers and impacts from the recursive-clone issue.

GitHub describes CVE-2026-113408 as path traversal involving a malicious server’s advertised branch reference. Under the documented conditions, a later reference update can write outside the intended reference directory.

CVE-2026-114467 concerns stack corruption when Git processes messages containing more signatures than expected. GitHub says a crafted signed tag used in a merge can trigger memory corruption and a potential denial of service.

CVE-2026-114469 involves an out-of-bounds read when a compressed binary patch expands beyond an expected size limit. A crafted patch can cause Git to crash, according to the announcement.

CVE-2026-105437 concerns heap corruption during very large merges, including cases involving many conflicts and a large conflict-marker setting. GitHub says the issue affects local merges and services that merge untrusted content.

Finally, CVE-2026-114466 affects features of Git’s fast-import stream processing that can access files outside the repository. The fix restricts the affected features when supplied through an input stream unless unsafe features are explicitly enabled.

These issues should not all be described as the same remote-code-execution flaw. Each has its own trigger and potential impact. Administrators should review the vendor guidance relevant to the operations their systems perform.

GitHub’s Hosted and Enterprise Products

GitHub says it deployed fixes across GitHub.com, GitHub Enterprise Cloud and GitHub Enterprise Cloud with data residency. It also lists GitHub Enterprise Server updates in versions 3.19.15, 3.20.11, 3.21.9 and 3.22.4.

Administrators of self-managed GitHub Enterprise Server installations should consult the current release guidance and select an appropriate supported update. A hosted service being updated does not automatically patch a developer’s local Git installation or a separately managed build runner.

At the time of GitHub’s November 10 announcement, the company said it was coordinating releases of GitHub Desktop and the GitHub Copilot app containing patched Git versions. It also said Codespaces and GitHub Actions would receive patched Git versions.

Those statements describe the status in the announcement, not a guarantee that every later product update or custom runner has already been deployed. Organizations should check current product-specific guidance and verify the actual tools used in their environments.

Developer Workstations and Automated Builds

A developer may clone a repository from an unfamiliar source while investigating a bug, testing a contribution or evaluating a dependency. Automated systems can also retrieve repositories and submodules as part of a build or test workflow.

The Git vulnerability matters where a vulnerable Git client processes a specially crafted repository in the described way. The risk is especially relevant to systems that automatically perform recursive clones and hold credentials, network access or permissions useful to an attacker.

That does not mean every CI pipeline uses recursive clones or that every repository hosted on a public service is malicious. Exposure depends on the Git version, workflow configuration, source of the repository and privileges available to the process.

Organizations should inventory hosted and self-managed runners, container images and development environments. A patched developer laptop does not update an old build image, and a patched system Git may not update a copy embedded in an application.

Practical Actions for Developers

Check the Git installation in use

Identify the Git executable used by the command line and development tools, then compare its version with the applicable vendor guidance. Repeat the check for additional installations, including portable copies and applications that bundle Git.

On systems managed by a Linux distribution or enterprise software platform, use the distributor’s security advisory to determine whether a package includes the fix. Backported patches can make a fixed package’s version look different from an upstream release.

Install the supported update

GitHub recommends Git 2.56.1 or the patched release for the relevant maintenance series. Obtain the update from a trusted distributor and follow normal compatibility and change-management procedures.

After updating, verify the version used in the environment where repositories are cloned. For a container image or development workspace, rebuild or update the image and ensure the corrected version is deployed to the systems that run it.

Where Git is managed by an organization, users should follow the approved update process and report installations that cannot be updated through it. The presence of an update announcement does not prove the update reached every workstation.

Limit untrusted operations while updating

GitHub advises users who cannot update immediately to clone only from trusted servers and avoid recursively cloning untrusted repositories. It also recommends avoiding untrusted merges, tags, binary patches and fast-import streams while systems remain unpatched.

These precautions address different vulnerabilities in the release and are not a substitute for the fixes. A repository hosted on a familiar service may still contain untrusted content, so organizations should consider the origin and review of the repository itself.

A normal clone without automatic submodule initialization can reduce exposure to the specific recursive-clone scenario described, but it does not fix Git or eliminate the other five issues. Follow current vendor guidance and apply the update.

Practical Actions for Platform and CI Teams

Review build definitions for recursive cloning and submodule initialization, including templates reused across multiple projects. Identify which workflows accept external contributions or pull repositories whose contents are not fully controlled by the organization.

Update Git in runner images, build containers and service-side systems that process repositories. Verify the deployed image or executable rather than assuming that a central package update reaches every runner.

Limit build credentials and permissions to what a job requires. Short-lived credentials, restricted network access and isolation between jobs can reduce the consequences of unexpected code execution, although they do not repair a vulnerable Git installation.

Hosting services that merge or inspect untrusted content should also assess the other security fixes. The recursive-clone flaw is not the only issue in the release that can affect automated processing.

Investigating Suspicious Activity

The Git and GitHub announcements describe vulnerabilities and fixes; they do not identify a confirmed victim count or a specific campaign exploiting CVE-2026-111760. NewsFlayer has not independently reproduced the flaw or analyzed a malicious repository.

If a team suspects that a crafted repository was processed on a vulnerable system, it should preserve relevant job logs, repository details and endpoint evidence, then involve its security or incident-response team.

Investigators should assess what credentials and network resources were available to the Git process, what code or commands ran and whether further changes occurred. A failed or incomplete clone alone does not prove exploitation, and a successful clone does not by itself prove the repository was safe.

Updating Git prevents the fixed vulnerable behavior but does not undo code that may already have run. Credential rotation, isolation or rebuilding may be appropriate where evidence supports concern about a compromised environment.

A Software Supply-Chain Reminder

The release highlights that source-control operations process data supplied by repositories and servers before a project’s application code is deliberately run. Security controls need to cover the tools and automation that retrieve code, not only the code reviewed afterward.

Submodule policies, trusted build environments and least-privilege credentials can help reduce exposure. They do not replace a patched Git client or a review of the other vulnerabilities addressed in the release. The separate Ethersphere software supply-chain attack also highlights the importance of protecting development and release workflows.

Conclusion

CVE-2026-111760 can allow attacker-controlled code execution during a recursive clone of a specially crafted repository, according to GitHub. The Git project has released Git 2.56.1 and patched maintenance versions for this and five separate security issues.

Developers and administrators should update the Git installations they actually use, including embedded copies and automated runners, and follow current vendor guidance while investigating any credible signs of compromise.

Source note: This article draws on the Git project’s release notes, GitHub’s security announcement, Git for Windows release notes and independent reporting by The Hacker News. NewsFlayer has not independently reproduced the vulnerabilities.

NewsFlayer — Bringing You the Latest Cybersecurity News from Around the World.