Skip to content

CodeWhale: Argument Injection in `git_show` Tool Allows Arbitrary File Write Without Approval

High severity GitHub Reviewed Published Jul 16, 2026 in codewhale-hq/Codewhale • Updated Sep 4, 2026

Package

npm codewhale (npm)

Affected versions

>= 0.8.41, < 0.8.64

Patched versions

0.8.64
cargo codewhale-tui (Rust)
>= 0.8.41, < 0.8.64
0.8.64
cargo deepseek-tui (Rust)
>= 0.3.27, <= 0.8.41
None
npm deepseek-tui (npm)
>= 0.3.27, < 0.8.41
0.8.41

Description

Maintainer resolution

The CodeWhale maintainers validated this report. The affected package ranges are recorded in the advisory metadata. Version 0.8.64 contains the fix in commit 9a34b5034d29f05d1f28fa61b04719ca6a741020. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.

Argument Injection in git_show Tool Allows Arbitrary File Write Without Approval

Overview

The git_show tool in DeepSeek-TUI executes git show with the model-supplied rev parameter passed unvalidated into the argv. git show honours the --output=<path> option, so a rev value beginning with --output= is interpreted as a flag rather than a revision. The tool is registered with ApprovalRequirement::Auto and declares ToolCapability::ReadOnly, so the write happens without a user prompt and contradicts the capability the catalog advertises to the model and the user.

This is the same vulnerability class as GHSA-72w5-pf8h-xfp4 (CVE-2026-45374): an auto-approved tool produces an effect outside the boundary the user consented to.

Impact

A malicious repository combined with prompt injection, the threat model already documented in CVE-2026-45311 (auto-loaded AGENTS.md is treated as instructions by the model) yields an unprompted arbitrary file write at the privilege of the user running DeepSeek-TUI.

Useful targets reachable as the invoking user:

  • ~/.ssh/authorized_keys
  • ~/.bashrc, ~/.zshrc, ~/.profile
  • ~/.gitconfig (chainable into RCE via core.editor)
  • ~/.config/**, ~/.aws/credentials, project source files

The written content is the git show rendering of HEAD commit hash, author/date header, indented commit message, and (when patch=true) diff hunks. The commit subject, body, author identity, and diff text are entirely attacker-controlled because the attacker owns the repository HEAD. The leading commit <hash> line prevents clean overwrite of formats that reject unknown tokens, but is silently ignorable in files parsed as comments-or-text (crontab, dotfiles consumed by tolerant readers) and is irrelevant for the destructive/DoS sub-case (clobbering ~/.ssh/authorized_keys locks the user out; clobbering a project file corrupts source).

Technical Details

Root Cause

crates/tui/src/tools/git_history.rs:

// L196-198
fn approval_requirement(&self) -> ApprovalRequirement {
    ApprovalRequirement::Auto
}

// L204-228 (excerpt)
async fn execute(&self, input: Value, context: &ToolContext) -> Result<ToolResult, ToolError> {
    let rev = required_str(&input, "rev")?;
    ...
    let mut args = vec![
        "show".to_string(),
        "--no-color".to_string(),
        "--no-ext-diff".to_string(),
    ];
    if patch { args.push(format!("--unified={unified}")); }
    else     { args.push("--no-patch".to_string()); }
    if stat  { args.push("--stat".to_string()); }
    args.push(rev.to_string());        // unvalidated, no `--end-of-options` sentinel
    ...
}

The JSON schema for rev is {"type": "string"} (L161-164) with no pattern, no enum, and no length cap. required_str performs no semantic validation. The argv has no --end-of-options separator between the trailing options and rev, so git's option parser keeps consuming flags from rev.

The same pattern in git_blame (L322-388) is tracked in a separate advisory.

Why --output Works

git show shares its option parser with git log / git diff, which expose --output=<file>. The implementation opens the path with O_WRONLY | O_CREAT | O_TRUNC and writes the formatted output there. No permission check beyond the filesystem's own running as the user is sufficient to clobber anything the user owns.

Proof of Concept

The vulnerable argv assembled by the tool when invoked with
{"rev": "--output=/home/victim/.bashrc"} is equivalent to:

git show --no-color --no-ext-diff --no-patch --stat --output=/home/victim/.bashrc

Reproduced against system git as a non-root user:

$ id
uid=1001(lowtest) gid=1001(lowtest) groups=1001(lowtest)

$ cd /tmp/lp && git init -q
$ echo a > a.txt && git add a.txt
$ git -c user.email=a@b -c user.name=a commit -q -m "lol"

$ git show --no-color --no-patch "--output=/home/lowtest/.bashrc_clobbered" HEAD
$ ls -la /home/lowtest/.bashrc_clobbered
-rw-rw-r-- 1 lowtest lowtest 128 May 19 07:05 /home/lowtest/.bashrc_clobbered

End-to-end exploitation path:

  • Attacker publishes a repository whose AGENTS.md instructs the model to call git_show with rev set to a crafted --output= string targeting a file in the victim's home directory. The same auto-load pathway documented in CVE-2026-45311 applies.
  • Victim opens the repository in DeepSeek-TUI and issues any prompt that exercises the agent loop.
  • The model issues the tool call. Because approval_requirement() returns Auto, no approval UI is shown.
  • git show --output=<path> overwrites the target file with attacker-controlled commit metadata and diff text.

Remediation

Two changes in crates/tui/src/tools/git_history.rs:

Insert an end-of-options sentinel before rev so git stops parsing flags:

args.push("--end-of-options".to_string());
args.push(rev.to_string());

Reject rev values that begin with - (or restrict to a revision-shape
regex ^[A-Za-z0-9._/^~@:{}-]+$ after the leading character check):

if rev.starts_with('-') {
    return Err(ToolError::invalid_input("rev must not start with '-'"));
}

A regression test mirroring run_tests_requires_user_approval (test_runner.rs:197) should assert that rev = "--output=/tmp/x" is rejected.

References

@Hmbown Hmbown published to codewhale-hq/Codewhale Jul 16, 2026
Published by the National Vulnerability Database Aug 18, 2026
Published to the GitHub Advisory Database Sep 4, 2026
Reviewed Sep 4, 2026
Last updated Sep 4, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction Passive
Vulnerable System Impact Metrics
Confidentiality None
Integrity High
Availability High
Subsequent System Impact Metrics
Confidentiality None
Integrity High
Availability High

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(40th percentile)

Weaknesses

External Control of File Name or Path

The product allows user input to control or influence paths or file names that are used in filesystem operations. Learn more on MITRE.

Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')

The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string. Learn more on MITRE.

CVE ID

CVE-2026-75913

GHSA ID

GHSA-7j5w-7r7x-9v27

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.