OESA-2026-4623: libgit2 security update
libgit2 is a portable, pure C implementation of the Git core methods provided as a re-entrant linkable library with a solid API, allowing you to write native speed custom Git applications in any language which supports C bindings. Security Fix(es):
libgit2 versions before 1.8.7 and 1.9.0 before 1.9.7 built with the libssh2 SSH backend (USESSH=libssh2) contain a shell command injection vulnerability that allows remote attackers to execute arbitrary commands on an SSH server by supplying a repository path containing unescaped shell metacharacters such as single quotes, semicolons, or pipes. The genproto() function in sshlibssh2.c inserts the repository path directly into a shell command string without escaping special characters before passing it to libssh2channelexec(), enabling an attacker to craft a malicious submodule URL in a .gitmodules file that, when processed during a recursive clone, causes the remote server's shell to interpret injected commands under the victim's SSH user account.(CVE-2026-5917)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
openeuler/libgit2to a version that resolves this vulnerability.Fixed in 1.7.2-3.oe2403sp4 - Upgrade
Upgrade
libgit2to a version that resolves this vulnerability.Fixed in 1.8.7 - Upgrade
Upgrade
libgit2to a version that resolves this vulnerability.Fixed in 1.9.7
Event History
Frequently Asked Questions
Which deployments are affected?
Affected deployments use libgit2 versions before 1.8.7, or versions from 1.9.0 before 1.9.7, and were built with the libssh2 SSH backend (USE_SSH=libssh2). The issue is specific to that SSH backend configuration.
What must an attacker provide to trigger exploitation?
An attacker needs to supply a repository path containing shell metacharacters, for example single quotes, semicolons, or pipes. A malicious submodule URL in a .gitmodules file can carry that path and trigger the issue when it is processed during a recursive clone.
Under whose account do injected commands run?
The remote SSH server interprets the injected commands under the victim's SSH user account. This occurs because the repository path is placed into a shell command passed through the libssh2 SSH backend without escaping special characters.