Bug 2514520

Summary: CVE-2026-5917 rust-tokei: libgit2: Arbitrary code execution via shell command injection in SSH backend [epel-all]
Product: [Fedora] Fedora EPEL Reporter: Ganesh <gnaik>
Component: rust-tokeiAssignee: Ben Beasley <code>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: epel10CC: code, decathorpe, kanru, rust-sig
Target Milestone: ---Keywords: Security, SecurityTracking
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: {"flaws": ["bf1b81d9-4fec-4354-8234-5cf1cd665927"]}
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2026-08-18 20:40:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2514416    

Description Ganesh 2026-08-12 08:16:57 UTC 
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

libgit2 versions v0.27.0 through v1.9.0 built with the libssh2 SSH backend (USE_SSH=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 gen_proto() function in ssh_libssh2.c inserts the repository path directly into a shell command string without escaping special characters before passing it to libssh2_channel_exec(), 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.
Comment 1 Ben Beasley 2026-08-18 20:40:40 UTC 
This package only uses libgit2 indirectly via the Rust git2 crate, and that only as a test dependency, so (1) I can’t see what could possibly be done here, rather than in libgit2 or rust-git2, and (2) the package can’t be affected by any vulnerabilities in a test dependency anyway.