| Package | Affected versions | Patched versions |
|---|---|---|
| codewhale-tui | ≥ 0.8.41, < 0.8.64 | 0.8.64 |
| deepseek-tui | ≥ 0.3.27, ≤ 0.8.41 | |
| codewhale | ≥ 0.8.41, < 0.8.64 | 0.8.64 |
| deepseek-tui | ≥ 0.3.27, < 0.8.41 | 0.8.41 |
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.
git_show Tool Allows Arbitrary File Write Without ApprovalThe 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.
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 filesThe 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).
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freecrates/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.
--output Worksgit 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.
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:
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.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.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.