CVE-2026-75911: CodeWhale project config allow_shell override enables arbitrary shell execution

CVE-2026-75911 · Severity: high · CVSS 7.8 · Published 2026-09-04

CodeWhale is an AI coding assistant that can execute shell commands on a developer's machine when explicitly enabled. A malicious or compromised repository can override the user's security setting by including a project configuration file that automatically enables shell execution. When a developer clones and opens such a repository in CodeWhale, the AI model gains unrestricted ability to run arbitrary commands without the developer's knowledge or consent.

Technologies: codewhale-tui (crates.io), deepseek-tui (crates.io). Vendors: crates.io.

Quick answers

Is CVE-2026-75911 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-75911 being exploited in the wild.
How severe is CVE-2026-75911?
High severity, with a CVSS score of 7.8, published 4 September 2026.
Which products and versions are affected?
codewhale-tui (crates.io) >= 0.8.41, < 0.8.64; deepseek-tui (crates.io) >= 0.8.6, <= 0.8.41.
Is there a fix for CVE-2026-75911?
A patch was published on 2026-07-16: Version 0.8.64 contains fix in commit 43563356b98c6b993085554da82e77370160a31c Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-75911 attacked?
It is attacked over the network or with local access.
Am I affected by CVE-2026-75911?
Check whether you run codewhale-tui (crates.io) or deepseek-tui (crates.io) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

Technical details

The vulnerability is a configuration injection flaw in CodeWhale's project config merge logic (`crates/tui/src/main.rs:5181-5182`). The code unconditionally copies the `allow_shell` boolean from `.codewhale/config.toml` into the session configuration without applying a tightening guard. Unlike `approval_policy` and `sandbox_mode` which enforce "relaxation-prevention" semantics (project config can only tighten restrictions), `allow_shell` lacks this validation. This allows an attacker to set `allow_shell = true` in a committed repository config, automatically enabling the AI model's shell execution tools (`exec_shell`, `task_shell_start`, `task_shell_wait`). The merge occurs automatically when entering a repository directory unless the user passes the rarely-known `--no-project-config` flag. With shell tools enabled, the AI model can execute arbitrary commands via `Command::new(program)` (lines 832, 991, 1152 in `shell.rs`), including many "safe" commands that bypass approval prompts (e.g., `ls`, `cat`, `git status`, `cargo build`). Attack preconditions: user must clone a malicious/compromised repository and run CodeWhale within it. Fix available in version 0.8.64 which applies proper tightening-only semantics to `allow_shell`.

Affected products

  • CodeWhale CodeWhale (npm) >=0.8.41, <0.8.64
  • CodeWhale codewhale-tui (Rust) >=0.8.41, <0.8.64
  • CodeWhale deepseek-tui (Rust) >=0.8.6, <=0.8.41
  • CodeWhale deepseek-tui (npm) >=0.8.6, <0.8.41

Identifiers

  • CVE-2026-75911
  • GHSA-gx45-xrj5-g6c4

Timeline

  • 2026-07-16: disclosed
  • 2026-07-16: advisory
  • 2026-07-16: patched: Version 0.8.64 contains fix in commit 43563356b98c6b993085554da82e77370160a31c
  • 2026-09-04: kev added

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.