CVE-2026-106058 in GitAhead
Summary
by MITRE • 10/07/2026
GitAhead through 2.7.1 contains an OS command injection vulnerability in src/git/Filter.cpp that allows malicious repositories to execute commands by substituting crafted filenames into clean/smudge filter commands. Attackers can ship files named with $(command) selected via .gitattributes so checkout or staging runs the command through bash -c as the victim.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
GitAhead versions up to 2.7.1 are susceptible to an operating system command injection vulnerability located within the src/git/Filter.cpp module of its source code. This security flaw arises from improper neutralization of special elements used in OS commands, specifically during the processing of clean and smudge filters associated with Git attributes. The vulnerability allows for arbitrary command execution by attackers who can manipulate filenames to include shell metacharacters that are interpreted as executable instructions rather than literal file names.
The technical mechanism of this exploit relies on the interaction between GitAhead's handling of .gitattributes files and its underlying git filter chain implementation. When a repository is checked out or staged, GitAhead processes any defined filters for specific file patterns. If an attacker controls the contents of a target repository, they can craft a .gitattributes file that assigns a clean or smudge filter to certain paths. By naming these files with strings such as $(command), which are valid in many shell contexts but dangerous when passed directly to a command interpreter, the application inadvertently triggers code execution. The vulnerability is exacerbated because GitAhead invokes bash -c to execute these filters, passing the crafted filename directly into the shell without adequate sanitization or escaping of special characters like parentheses and dollar signs.
From an operational perspective, this vulnerability poses a severe risk to users who open repositories from untrusted sources. An attacker can distribute a malicious repository containing specially named files configured via .gitattributes. When a victim uses GitAhead to clone, pull, stage, or checkout these files, the application will execute arbitrary commands on the host system with the privileges of the user running GitAhead. This could lead to complete compromise of the local environment, including data exfiltration, installation of malware, pivoting to other systems within the network, or modification of critical system configurations. The impact is particularly acute because it does not require direct interaction beyond opening a repository, making social engineering attacks involving malicious repositories highly effective.
This vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command and falls under MITRE ATT&CK technique T1059 Command and Scripting Interpreter, specifically subtechnique T1059.004 Unix Shell. It represents a classic case where input validation fails to distinguish between data intended for display or storage and code intended for execution within the shell context. The root cause lies in the assumption that filenames are safe strings rather than potential command payloads when passed through system calls involving shell interpreters.
Mitigation strategies primarily involve updating GitAhead to version 2.7.2 or later, where this issue has been addressed by implementing proper input sanitization and avoiding direct invocation of bash -c with unsanitized user-controlled inputs. In the interim, users should exercise extreme caution when opening repositories from untrusted sources, particularly those that include .gitattributes files defining custom filters. Security teams can also implement monitoring for unusual process creation events involving git or shell interpreters spawned by GitAhead processes to detect potential exploitation attempts in real-time. Additionally, enforcing strict code review policies and static analysis tools focused on command injection patterns during the development of similar applications can prevent recurrence of such flaws.