CVE-2026-75912: Argument Injection and Arbitrary File Disclosure in CodeWhale Git Tools

CodeWhale is an AI-assisted terminal user interface (TUI) and coding companion that incorporates automated tools to interact with Git repositories. Among these integration capabilities are the git_blame and git_show helper utilities, which parse local codebases and structural changes to enrich LLM contexts.

The attack surface exists where CodeWhale tools process user-supplied parameters to construct and execute operating system commands. Specifically, the software fails to sanitize or constrain the revision (rev) parameter, which determines which branch, commit hash, or tag is queried by the local git client.

Because this component exposes programmatic controls directly to inputs generated by potentially untrusted sources (such as third-party code modifications or direct agent instructions), improper input sanitization leads to command-line flag injection. This vulnerability is formally classified as CWE-88 (Improper Neutralization of Argument Delimiters in a Command).

The root cause of this vulnerability lies in the dynamic assembly of external process arguments without validation. In Rust, standard application development leverages the std::process::Command struct to spawn system processes.

While std::process::Command does not execute commands within an intermediate system shell like /bin/sh or cmd.exe by default, it does not prevent argument or option injection. If a user-supplied string begins with a hyphen character (-), the underlying operating system executes the target binary, and that binary processes the argument as an administrative switch or configuration option rather than as a positional file or revision name.

In CodeWhale's implementation, the unvalidated rev parameter is passed directly into the process argument array for git blame. The git-blame binary supports the --contents <file> option, which instructs the command to perform its history analysis using a specified disk file's actual contents rather than the database state. Consequently, an attacker can input an option-shaped string such as --contents=/etc/passwd to force the git client to read local files outside the target repository context.

The vulnerability was mitigated in commit 9a34b5034d29f05d1f28fa61b04719ca6a741020 by implementing validation routines that block leading hyphens, control characters, and empty parameters.

Prior to the patch, both GitShowTool and GitBlameTool retrieved the revision parameter from the tool request input block and directly passed it to the git executable wrapper. Below is the comparative code change implemented in crates/tui/src/tools/git_history.rs to address this exposure:

// Vulnerable vs. Patched execution context in crates/tui/src/tools/git_history.rs
 
@@ -204,6 +204,7 @@ impl ToolSpec for GitShowTool {
     async fn execute(&self, input: Value, context: &ToolContext) -> Result<ToolResult, ToolError> {
         let rev = required_str(&input, "rev")?;
+        validate_git_rev(rev)?; // Added input validation before executing system process
         let git_ctx = resolve_git_context(context, optional_str(&input, "path"))?;
         let patch = optional_bool(&input, "patch", true);
...
@@ -339,6 +340,7 @@ impl ToolSpec for GitBlameTool {
         let rev = optional_str(&input, "rev").unwrap_or("HEAD");
+        validate_git_rev(rev)?; // Added option validation block to prevent parameter abuse
         let start_line = optional_u64(&input, "start_line", DEFAULT_BLAME_START_LINE).max(1);

To ensure complete isolation, the maintainers defined a rigorous verification helper named validate_git_rev that screens incoming revision strings:

fn validate_git_rev(rev: &str) -> Result<(), ToolError> {
    let trimmed = rev.trim();
    if trimmed.is_empty() {
        return Err(ToolError::invalid_input(
            "git revision must not be empty".to_string(),
        ));
    }
    // Ensure the parameter is not processed as a command-line flag
    if trimmed.starts_with('-') {
        return Err(ToolError::invalid_input(
            "git revision must not start with '-'".to_string(),
        ));
    }
    // Prevent execution flow truncation and parser manipulation
    if trimmed.chars().any(|ch| ch == '\0' || ch.is_ascii_control()) {
        return Err(ToolError::invalid_input(
            "git revision must not contain control characters".to_string(),
        ));
    }
    Ok(())
}

This validator enforces critical constraints. The call to .trim() prevents attackers from using spaces to bypass the starts_with('-') check, while the control character filter stops binary path modifications using null bytes.

Exploitation of CVE-2026-75912 requires providing a manipulated tool payload to the CodeWhale execution layer. This can occur directly if the tool allows direct interface interactions, or indirectly if an attacker manages to trigger prompt-injection payloads via malicious repositories or files reviewed by the AI companion.

An attacker supplies a structured JSON command payload containing the target option injection within the rev argument:

{
  "path": "Cargo.toml",
  "rev": "--contents=/etc/passwd"
}

Upon execution, CodeWhale runs the system command without verification, generating the following process execution vector:

git blame --contents=/etc/passwd Cargo.toml

Because the git-blame process is instructed to read from /etc/passwd, it parses the sensitive configuration file line-by-line and decorates each record with synthetic commit headers. The resultant output stream is then returned to the AI context as the command execution output:

00000000 (Not Committed Yet 2026-06-21 22:13:26 +0000 1) root:x:0:0:root:/root:/bin/bash
00000000 (Not Committed Yet 2026-06-21 22:13:26 +0000 2) daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin

This output exposes system configuration values and local credentials directly, leading to immediate information exposure.

The security implications of CVE-2026-75912 are significant. Successful exploitation grants attackers read-access to any arbitrary file on the host filesystem that the executing process user has permissions to access.

In cloud development environments, workspace instances, or shared build pipelines, this read-access exposes sensitive parameters including environment variables, private developer keys (e.g., SSH keys, AWS access secrets), configuration files, and proprietary source code files. While the vulnerability does not directly permit write-access or code execution, the disclosed credentials can be used to pivot and achieve broader network compromise.

The CVSS v4.0 rating is 8.3 (High) due to the low complexity of the attack vector coupled with high subsequent confidentiality impacts. The scope change metric is marked as High because the vulnerability leaks data across isolated file systems and outputs it back to the processing application layer.