CVE-2026-75913: CodeWhale: git_show argument injection enables file write

GHSA-7j5w-7r7x-9v27CRITICALPoC AVAILABLECISA: ATTEND
Published August 18, 2026
CISO Take

CodeWhale's git_show tool passes an unvalidated, model-supplied revision string straight into git's argv without an --end-of-options sentinel, so a value starting with --output= is read as a git flag instead of a commit reference, turning a tool the agent auto-approves as 'read-only' into an arbitrary file writer at the invoking user's privilege. This matters because the trigger doesn't require a user to run anything malicious directly — a booby-trapped repository combined with prompt injection can steer the coding agent into calling git_show with the crafted rev, silently planting content in files like ~/.ssh/authorized_keys, ~/.bashrc, or ~/.gitconfig to gain persistence or shell hijack. There is no public exploit or Nuclei template yet, EPSS sits at a low 0.0033 and it isn't in CISA KEV, so this is a design-flaw-class risk rather than something being mass-exploited in the wild today — but the CVSS 9.3 (network, low complexity, no privileges required, scope change) reflects how severe a successful hit is once a developer opens the wrong repository. Teams running codewhale or codewhale-tui should upgrade to 0.8.64 immediately; in the interim, treat 'read-only' auto-approved agent tools as untrusted-input execution paths and monitor git-related dotfiles and authorized_keys for unexpected writes.

Sources:NVDGitHub AdvisoryEPSSATLAS

What is the risk?

Critical on paper (CVSS 9.3, scope change, high confidentiality-independent integrity/availability impact) but currently low real-world exploitation pressure: EPSS is 0.0033, there is no CISA KEV listing, no public PoC, and no Nuclei template. The gating factor is user interaction — a developer must open/interact with a malicious repository while using the vulnerable CodeWhale version — which narrows the exploitable population but does not require any special privileges from the attacker. The absence of downstream npm/cargo dependents (0 recorded) limits blast radius to direct users of codewhale/codewhale-tui and the related deepseek-tui lineage rather than a transitive supply-chain wave, but any individual hit is severe: unprompted arbitrary file write at full user privilege, including SSH authorized_keys and shell rc files, is effectively a path to persistent account takeover.

How does the attack unfold?

Initial Access
Attacker plants prompt-injection content in a repository (README, comments, or issue text) designed to steer an AI coding agent into calling git_show with a malicious revision string.
AML.T0051.001
Tool Invocation
The auto-approved, presumed-read-only git_show tool is invoked by the agent with the attacker-controlled rev parameter beginning with --output=.
AML.T0053
Argument Injection
Because CodeWhale omits an --end-of-options sentinel, git interprets the rev value as a flag rather than a revision, redirecting output to an arbitrary file path.
Impact
Arbitrary content is written to sensitive files such as ~/.ssh/authorized_keys, granting the attacker persistent unauthorized access at the victim's privilege level.
AML.T0012

What systems are affected?

PackageEcosystemVulnerable RangePatched
DeepSeek TUInpm>= 0.8.41, < 0.8.640.8.64
DeepSeek TUIcargo>= 0.8.41, < 0.8.640.8.64
DeepSeek TUInpm>= 0.3.27, < 0.8.410.8.41
DeepSeek TUIcargo>= 0.3.27, <= 0.8.41No patch

How severe is it?

CVSS 3.1
9.3 / 10
EPSS
0.5%
chance of exploitation in 30 days
Higher than 41% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Moderate
Exploitation Confidence
medium
○CISA SSVC: Public PoC
○Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVACPRUISCIA
AVNetwork
ACLow
PRNone
UIRequired
SChanged
CNone
IHigh
AHigh

What should I do?

1 step
  1. Upgrade codewhale and codewhale-tui to >= 0.8.64 immediately; upgrade deepseek-tui to >= 0.8.41 (npm) — note the cargo deepseek-tui line has no patched version listed, so cargo users should migrate to codewhale-tui or pin away from the vulnerable range. As a workaround if upgrading is delayed, disable auto-approval for git_show/git-wrapping tools and require explicit human confirmation before any git subprocess call with model-supplied arguments. Detection guidance: audit shell history and file-integrity monitoring for unexpected modifications to ~/.ssh/authorized_keys, ~/.bashrc, ~/.gitconfig, and other dotfiles on developer workstations running CodeWhale in the vulnerable range; review any recently cloned/interacted-with repositories for suspicious rev-like strings beginning with '--' embedded in file content, commit messages, or README text used for prompt injection.

What does CISA's SSVC say?

DecisionAttend
Exploitationpoc
AutomatableNo
Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2.4-AI system verification and validation before deployment
NIST AI RMF
MANAGE-2.3-Procedures are followed to respond to and recover from previously unknown risks
OWASP LLM Top 10
LLM01-Prompt InjectionLLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-75913?

CodeWhale's git_show tool passes an unvalidated, model-supplied revision string straight into git's argv without an --end-of-options sentinel, so a value starting with --output= is read as a git flag instead of a commit reference, turning a tool the agent auto-approves as 'read-only' into an arbitrary file writer at the invoking user's privilege. This matters because the trigger doesn't require a user to run anything malicious directly — a booby-trapped repository combined with prompt injection can steer the coding agent into calling git_show with the crafted rev, silently planting content in files like ~/.ssh/authorized_keys, ~/.bashrc, or ~/.gitconfig to gain persistence or shell hijack. There is no public exploit or Nuclei template yet, EPSS sits at a low 0.0033 and it isn't in CISA KEV, so this is a design-flaw-class risk rather than something being mass-exploited in the wild today — but the CVSS 9.3 (network, low complexity, no privileges required, scope change) reflects how severe a successful hit is once a developer opens the wrong repository. Teams running codewhale or codewhale-tui should upgrade to 0.8.64 immediately; in the interim, treat 'read-only' auto-approved agent tools as untrusted-input execution paths and monitor git-related dotfiles and authorized_keys for unexpected writes.

Is CVE-2026-75913 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-75913, increasing the risk of exploitation.

How to fix CVE-2026-75913?

Upgrade codewhale and codewhale-tui to >= 0.8.64 immediately; upgrade deepseek-tui to >= 0.8.41 (npm) — note the cargo deepseek-tui line has no patched version listed, so cargo users should migrate to codewhale-tui or pin away from the vulnerable range. As a workaround if upgrading is delayed, disable auto-approval for git_show/git-wrapping tools and require explicit human confirmation before any git subprocess call with model-supplied arguments. Detection guidance: audit shell history and file-integrity monitoring for unexpected modifications to ~/.ssh/authorized_keys, ~/.bashrc, ~/.gitconfig, and other dotfiles on developer workstations running CodeWhale in the vulnerable range; review any recently cloned/interacted-with repositories for suspicious rev-like strings beginning with '--' embedded in file content, commit messages, or README text used for prompt injection.

What systems are affected by CVE-2026-75913?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI coding assistants / CLI tools.

What is the CVSS score for CVE-2026-75913?

CVE-2026-75913 has a CVSS v3.1 base score of 9.3 (CRITICAL). The EPSS exploitation probability is 0.48%.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI coding assistants / CLI tools

MITRE ATLAS Techniques

AML.T0010.005AI Agent Tool
AML.T0012Valid Accounts
AML.T0051.001Indirect
AML.T0053AI Agent Tool Invocation

Compliance Controls Affected

ISO 42001: A.6.2.4
NIST AI RMF: MANAGE-2.3
OWASP LLM Top 10: LLM01, LLM06

What are the technical details?

Original Advisory

CodeWhale versions >= 0.3.27 and < 0.8.64 (published as deepseek-tui >= 0.3.27 and < 0.8.41 on npm and 0.3.27 through 0.8.41 on crates.io, and as codewhale / codewhale-tui >= 0.8.41 and < 0.8.64) contain an argument injection vulnerability in the git_show tool. The model-supplied rev parameter is passed unvalidated into the git show argv without an --end-of-options sentinel, so a value beginning with --output= is interpreted as a git flag. Because the tool is registered as auto-approved and advertised as read-only, an attacker (via a malicious repository combined with prompt injection) can cause an unprompted arbitrary file write at the privilege of the invoking user, targeting sensitive files such as ~/.ssh/authorized_keys, ~/.bashrc, or ~/.gitconfig. Fixed in codewhale / codewhale-tui 0.8.64 by adding rev validation; the deprecated deepseek-tui crate has no fixed release.

Exploitation Scenario

An attacker publishes or compromises a public repository containing hidden prompt-injection text (e.g., in a README, code comment, or issue) designed to instruct an AI coding agent to invoke git_show on a crafted revision string such as '--output=/home/user/.ssh/authorized_keys'. A developer using a vulnerable CodeWhale version opens or asks the agent to inspect that repository; the agent, trusting the auto-approved 'read-only' git_show tool, calls it with the injected rev value. Because CodeWhale does not insert a '--' sentinel before the rev argument, git interprets --output= as a flag rather than a revision, writing arbitrary content into the resolved path with the developer's OS privileges. The attacker's payload (e.g., their own SSH public key) is dropped into authorized_keys, giving them durable remote access to the developer's machine without ever triggering an explicit file-write warning.

Weaknesses (CWE)

CWE-73 — 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.

  • [Architecture and Design] When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.
  • [Architecture and Design, Operation] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:H

Timeline

Published
August 18, 2026
Last Modified
October 29, 2026
First Seen
August 18, 2026

Related Vulnerabilities