External risk intelligence

libgit2 SSH Command Injection Vulnerability

CVE advisorySeverity: HIGH (CVSS 8.6)

CVE-2026-5917

This vulnerability affects a low-level library (libgit2), not a direct network service. Exploitation requires a user to perform an action, such as executing a recursive clone on a malicious repository. Because the impact depends on client-side interaction rather than reaching a public-facing network service, it is unlikely to be exposed as an external attack surface in most environments.

OS Command Injection

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This CVE describes a vulnerability in the libgit2 library when using its SSH backend. If a specially crafted repository path is processed, it could allow an attacker to execute commands on the server. The main concern is confirming if this library is used and if affected configurations are exposed.

Code library allows attackers to run commands.
Affects how repositories are handled remotely.
Confirm relevance and any exposure.

Attack Path

How an attacker could exploit the issue

An attacker can execute arbitrary commands on an SSH server by tricking a user into cloning a malicious repository. This involves crafting a .gitmodules file with a specially formatted submodule URL that contains unescaped shell metacharacters. When libgit2 processes this file during a recursive clone, the server's shell interprets the injected commands.

User clones malicious repository.
Crafted submodule URL triggers injection.
Arbitrary command execution on server.

Live Threat

Current exploitation, exposure, and threat context

When libgit2 is built with the libssh2 SSH backend, a vulnerability in the `gen_proto()` function could allow remote attackers to execute arbitrary commands on an SSH server. This occurs when a specially crafted submodule URL in a `.gitmodules` file is processed during a recursive clone, leading to the injection of commands into the victim's SSH user account.

Server-side code execution.
Malicious repository processed by user.
Compromise of victim's SSH account.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability in libgit2's SSH backend requires action from teams managing code repositories and the underlying infrastructure that hosts them, as well as the security team responsible for network exposure. The initial step is to identify all systems where libgit2 with the libssh2 backend is deployed, determine their reachability and business criticality, and then locate the specific asset owners. Remediation planning should then proceed based on the identified risks.

App and infrastructure owners should lead remediation.
Verify libssh2 backend usage and repository path handling.
Plan maintenance for affected systems.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is libgit2 and why is it used?

libgit2 is a portable, pure C implementation of the Git core methods. Developers use this library to add Git repository capabilities—such as cloning, branching, and commit management—directly into their own software applications, services, or internal tooling rather than relying on the Git command-line interface.

What does CWE-78 mean for CVE-2026-5917?

CVE-2026-5917 is categorized under CWE-78, which is the weakness class for OS Command Injection. In this instance, the library fails to properly filter special characters in repository paths. Because the code passes these inputs directly to a system shell, an attacker can append their own commands to the legitimate Git process, forcing the server to execute unintended actions.

How is this vulnerability triggered?

The flaw is triggered when a user performs a recursive clone on a malicious Git repository containing a crafted .gitmodules file. Simply viewing or hosting a file is not enough; the library must actively process the submodule URL. If your application does not use the libssh2 backend or does not perform recursive clones, it does not encounter the vulnerable code path.

Is my system at risk?

According to Halo Surface Signal, this vulnerability is unlikely to be exposed as an external attack surface because it involves a low-level library rather than a direct network service. The primary risk is not from automated internet scanning, but rather from internal processes that might trigger a recursive clone of an untrusted or compromised repository.

What are the first steps for remediation?

Start by auditing your environment to locate applications that link against libgit2 specifically configured with the libssh2 backend. You do not need to hunt for network exposures immediately; instead, focus on identifying which internal services perform recursive clones of repositories. Once identified, prioritize these systems for library updates or security configuration changes.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.