CVE-2026-11968: TortoiseGit Blame Argument Injection Leading to Arbitrary File Write

Technical summary

CVE-2026-11968 is an argument injection vulnerability in TortoiseGitBlame, a graphical blame viewer component of TortoiseGit. The vulnerability arises from insufficient validation of filenames stored in Git history. When a user opens the Blame view on a repository containing specially crafted filenames, these filenames are passed unsanitized to system commands, allowing injection of additional arguments. This can result in arbitrary file write operations, bypassing normal access controls. The issue is rooted in CWE-88 (Argument Injection / Improper Neutralization of Argument Delimiters), where user-controlled input from Git metadata is not properly escaped before being used in command construction.

Business impact

A developer who clones or accesses a malicious repository and views the blame history could have files created or overwritten on their workstation. This could lead to code injection (if executables or scripts are written), credential theft (if configuration files are modified), or system compromise. For organizations where developers regularly review external or untrusted repositories, this represents a supply-chain-adjacent risk: a compromised upstream project could use crafted Git history to compromise contributor machines.

Affected systems

TortoiseGit installations that include the Blame feature are affected. The vulnerability requires local file system access and user interaction (opening Blame on a malicious repository). Patches and affected version specifics should be verified against the official TortoiseGit security advisory. Systems where users frequently interact with third-party repositories or where repository code review is a standard workflow face higher exposure.

Exploitability

Exploitation requires social engineering or repository trust abuse: an attacker must convince a developer to open a repository containing malicious filenames in the Blame viewer. The attack does not require elevated privileges on the target system, nor does it require a network connection once the repository is cloned. The barrier is moderate because it depends on user action, but repositories are often viewed as semi-trusted sources. No known active exploitation is tracked in the KEV catalog as of this writing.

Remediation

Apply the security patch released by the TortoiseGit project. Verify the patch version against the official TortoiseGit advisory, as version numbers are subject to change. Immediately after patching, open any repositories you may have previously inspected with the Blame feature to confirm no unexpected files were created. Consider a file system audit on developer machines to detect any suspicious file additions during the vulnerability window.

Patch guidance

Download and install the patched version of TortoiseGit directly from the official TortoiseGit homepage or through your organization's software distribution channel. Do not rely on in-app auto-update alone; verify the version number matches the vendor's recommended patch release. Organizations should prioritize deployment to developers who regularly review external repositories, security researchers, and code review platforms. Test the patch in a non-production environment before rolling out to your developer fleet to ensure compatibility with existing workflows.

Detection guidance

Monitor for unexpected file creation or modification in user home directories and workspace folders, particularly around Git repository directories. Log the execution of TortoiseGitBlame (TortoiseGitBlame.exe) and correlate with file system events. Check for command-line or process arguments that appear to contain path traversal sequences or unusual whitespace/special characters. File integrity monitoring on critical directories (Documents, source code folders) can alert you to unauthorized writes. Query Git logs for filenames containing backticks, semicolons, ampersands, pipes, or other shell metacharacters that might indicate attack preparation.

Why prioritize this

Although the CVSS score is moderate (5.5), the integrity impact is high: arbitrary file write is a serious consequence. The local attack surface and requirement for user interaction limit the immediate threat, but the attack is simple to execute once a malicious repository is in play. Organizations with developers who interact with external or community repositories should prioritize patching. The vulnerability is not yet in active exploitation (KEV status is false), which provides a narrow window to patch before weaponization becomes likely.

Risk score, explained

The CVSS v3.1 score of 5.5 (Medium) reflects a local attack vector with no privileges required and low attack complexity, balanced against the requirement for user interaction. The impact is high for integrity (arbitrary file write) but none for confidentiality or availability. The score appropriately captures that this is a serious local integrity issue that is moderately difficult to exploit in the wild, but should not be dismissed given the prevalence of Git workflows in software development.

Frequently asked questions