CVE-2026-75911

CodeWhale versions before 0.8.64 fail to properly validate the allow_shell configuration parameter from project config files, allowing attackers to enable arbitrary shell command execution by committing a malicious .codewhale/config.toml file to a repository. When a user clones and opens the repository in CodeWhale, the AI model gains access to exec_shell and task_shell tools, enabling execution of arbitrary shell commands on the victim's machine without explicit user consent.

CodeWhale versions before 0.8.64 fail to properly validate the allow_shell configuration parameter from project config files, allowing attackers to enable arbitrary shell command execution by committing a malicious .codewhale/config.toml file to a repository. When a user clones and opens the repository in CodeWhale, the AI model gains access to exec_shell and task_shell tools, enabling execution of arbitrary shell commands on the victim's machine without explicit user consent.

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 43563356b98c6b993085554da82e77370160a31c. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.

Summary

A malicious .codewhale/config.toml or .deepseek/config.toml committed to a repository can silently set allow_shell = true for any user who clones and opens the repository in CodeWhale. This enables the AI model's exec_shell tool, granting arbitrary shell command execution on the victim's machine without the user's explicit opt-in. The approval_policy and sandbox_mode fields correctly enforce tightening-only semantics from project config, but allow_shell has no such guard, contradicting the intent of GHSA-72w5-pf8h-xfp4 which established allow_shell as an opt-in security boundary.

Details

The project config merge function at crates/tui/src/main.rs:5181-5182 (v0.8.50) unconditionally copies the allow_shell boolean from a project-level config file into the live session config:

if let Some(v) = table.get("allow_shell").and_then(toml::Value::as_bool) {
    config.allow_shell = Some(v);
}

No tightening guard exists for allow_shell, unlike approval_policy (lines 5144-5158, guarded by project_approval_policy_is_allowed) and sandbox_mode (lines 5161-5171, guarded by project_sandbox_mode_is_allowed). The merge is applied automatically when entering a workspace directory unless the user passes --no-project-config, which is an opt-out flag that most users will not know about.

Source of attacker-controlled input: The .codewhale/config.toml or .deepseek/config.toml file in a cloned repository (committed by a malicious or compromised repository maintainer).

Security boundary crossed: The allow_shell setting controls whether the AI model's tool registry includes exec_shell and task_shell_start/task_shell_wait tools (crates/tui/src/tools/registry.rs:928-932). When allow_shell = false (the default), these tools are excluded. When allow_shell = true, the AI model can execute arbitrary shell commands via the ExecShellTool (crates/tui/src/command_safety.rs).

Sink reached: Shell command execution via crates/tui/src/tools/shell.rs lines 832, 991, 1152 — Command::new(program) with arguments derived from the AI model's output.

Why existing mitigations do not prevent exploitation:

1. approval_policy tightening guard (lines 5144-5158) only blocks project configs from relaxing approval requirements. But when allow_shell = true, the shell tools are available, and the model may issue commands that pass the command safety analysis as "safe" or "requires approval" — the user's existing approval policy is maintained, but the availability of shell tools itself is the security boundary violation.
2. The command_safety.rs safety analysis allows many commands as "safe" (e.g., ls, cat, git status, cargo build). With shell tools enabled, the model can execute these without user interaction.
3. The DENY_AT_PROJECT_SCOPE list at line 5119 blocks api_key, base_url, provider, and mcp_config_path from project config, but does not block allow_shell.

Flow from source to sink:

1. User clones a repository containing .codewhale/config.toml with allow_shell = true
2. User runs codewhale in the repository directory
3. merge_project_config() at line 5211 reads the project config and sets config.allow_shell = Some(true)
4. The allow_shell value flows into allow_shell: yolo || config.allow_shell() which evaluates to true
5. Tool registry at registry.rs:928-929 includes shell tools via with_shell_tools()
6. The AI model can now execute shell commands through exec_shell

PoC

Environment: Any system with CodeWhale v0.8.50 built from source (commit 0072209d).

**Clean checkout…

CodeWhale versions before 0.8.64 fail to properly validate the allow_shell configuration parameter from project config files, allowing attackers to enable arbitrary shell command execution by committing a malicious .codewhale/config.toml file to a repository. When a user clones and opens the repository in CodeWhale, the AI model gains access to exec_shell and task_shell tools, enabling execution of arbitrary shell commands on the victim's machine without explicit user consent.

CodeWhale versions before 0.8.64 fail to properly validate the allow_shell configuration parameter from project config files, allowing attackers to enable arbitrary shell command execution by committing a malicious .codewhale/config.toml file to a repository. When a user clones and opens the repository in CodeWhale, the AI model gains access to exec_shell and task_shell tools, enabling execution of arbitrary shell commands on the victim's machine without explicit user consent.

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 43563356b98c6b993085554da82e77370160a31c. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.

Summary

A malicious .codewhale/config.toml or .deepseek/config.toml committed to a repository can silently set allow_shell = true for any user who clones and opens the repository in CodeWhale. This enables the AI model's exec_shell tool, granting arbitrary shell command execution on the victim's machine without the user's explicit opt-in. The approval_policy and sandbox_mode fields correctly enforce tightening-only semantics from project config, but allow_shell has no such guard, contradicting the intent of GHSA-72w5-pf8h-xfp4 which established allow_shell as an opt-in security boundary.

Details

The project config merge function at crates/tui/src/main.rs:5181-5182 (v0.8.50) unconditionally copies the allow_shell boolean from a project-level config file into the live session config:

if let Some(v) = table.get("allow_shell").and_then(toml::Value::as_bool) {
    config.allow_shell = Some(v);
}

No tightening guard exists for allow_shell, unlike approval_policy (lines 5144-5158, guarded by project_approval_policy_is_allowed) and sandbox_mode (lines 5161-5171, guarded by project_sandbox_mode_is_allowed). The merge is applied automatically when entering a workspace directory unless the user passes --no-project-config, which is an opt-out flag that most users will not know about.

Source of attacker-controlled input: The .codewhale/config.toml or .deepseek/config.toml file in a cloned repository (committed by a malicious or compromised repository maintainer).

Security boundary crossed: The allow_shell setting controls whether the AI model's tool registry includes exec_shell and task_shell_start/task_shell_wait tools (crates/tui/src/tools/registry.rs:928-932). When allow_shell = false (the default), these tools are excluded. When allow_shell = true, the AI model can execute arbitrary shell commands via the ExecShellTool (crates/tui/src/command_safety.rs).

Sink reached: Shell command execution via crates/tui/src/tools/shell.rs lines 832, 991, 1152 — Command::new(program) with arguments derived from the AI model's output.

Why existing mitigations do not prevent exploitation:

1. approval_policy tightening guard (lines 5144-5158) only blocks project configs from relaxing approval requirements. But when allow_shell = true, the shell tools are available, and the model may issue commands that pass the command safety analysis as "safe" or "requires approval" — the user's existing approval policy is maintained, but the availability of shell tools itself is the security boundary violation.
2. The command_safety.rs safety analysis allows many commands as "safe" (e.g., ls, cat, git status, cargo build). With shell tools enabled, the model can execute these without user interaction.
3. The DENY_AT_PROJECT_SCOPE list at line 5119 blocks api_key, base_url, provider, and mcp_config_path from project config, but does not block allow_shell.

Flow from source to sink:

1. User clones a repository containing .codewhale/config.toml with allow_shell = true
2. User runs codewhale in the repository directory
3. merge_project_config() at line 5211 reads the project config and sets config.allow_shell = Some(true)
4. The allow_shell value flows into allow_shell: yolo || config.allow_shell() which evaluates to true
5. Tool registry at registry.rs:928-929 includes shell tools via with_shell_tools()
6. The AI model can now execute shell commands through exec_shell

PoC

Environment: Any system with CodeWhale v0.8.50 built from source (commit 0072209d).

**Clean checkout…