CVE-2026-75915

CVE-2026-75915 is a high-severity security vulnerability in deepseek-tui (rust), affecting versions >= 0.8.32, <= 0.8.41. It is fixed in 0.8.41, 0.8.64.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

CodeWhale: js_execution leaks parent environment to model context via missing env scrub

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

js_execution exposes parent process environment to model-provided JavaScript

The js_execution tool spawns Node with tokio::process::Command::new without calling the child_env scrubber that exec_shell, the Python REPL, and the MCP launcher all use. Model-provided JavaScript reads process.env and the values flow back to the parent transcript as the tool's stdout, exposing API keys, cloud credentials, and forge tokens to the next model turn.

Details

In crates/tui/src/tools/js_execution.rs (v0.8.37, lines 91-105):

let temp_dir = tempfile::tempdir()
    .map_err(|e| ToolError::execution_failed(format!("tempdir failed: {e}")))?;
let script_path = temp_dir.path().join("js_execution.js");
tokio::fs::write(&script_path, code)
    .await
    .map_err(|e| ToolError::execution_failed(format!("tempfile write failed: {e}")))?;

let mut cmd = tokio::process::Command::new(&node);
cmd.arg(&script_path);
cmd.current_dir(workspace);

let output = tokio::time::timeout(Duration::from_secs(120), cmd.output())
    .await
    .map_err(|_| ToolError::Timeout { seconds: 120 })
    .and_then(|res| res.map_err(|e| ToolError::execution_failed(e.to_string())))?;

The Command is built without cmd.env_clear() and without the project's crate::child_env::apply_to_tokio_command helper. Every variable in the parent process environment is inherited by the spawned node.

For comparison, exec_shell (crates/tui/src/tools/shell.rs:790-792) and the Python REPL (crates/tui/src/repl/runtime.rs:238) both apply the scrubber:

child_env::apply_to_command(&mut cmd, child_env::string_map_env(&exec_env.env));

apply_to_tokio_command calls cmd.env_clear() and then re-installs only the keys that pass is_allowed_parent_env_key (PATH, HOME, USER, LANG/LC_*, TMPDIR, proxy variables, Windows toolchain context, terminal settings). Secret-bearing variables (DEEPSEEK_API_KEY, OPENAI_API_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, etc.) are not on the allowlist and are dropped before the child starts. The js_execution path bypasses both the env_clear and the allowlist.

Commit history makes the gap explicit. Commit e6d4eae fix(security): scrub child process environments (2026-05-08) introduced child_env.rs and rewrote exec_shell, the Python REPL, the MCP launcher, and main.rs to use it. Commit 2566f3c feat(tools): add js_execution tool (2026-05-12) added this file four days later and never picked up the helper.

The tool is described to the model and surfaced in the approval pane as "Run model-provided JavaScript code in local Node.js execution sandbox" (crates/tui/src/core/engine/turn_loop.rs:1174-1176). No sandbox is applied beyond a 120-second timeout; Node has full filesystem and network access in addition to the inherited environment. The wording understates the trust boundary that the user is being asked to cross.

In YOLO mode (auto_approve=true) the JS body runs without any prompt at all, so a single adversarial prompt-injection from a README, fetched web page, or MCP server output drains the parent environment to the next model turn.

PoC

A standalone Cargo test reproduces the unscrubbed-env behavior. Save as crates/tui/tests/js_execution_env_leak.rs and run with cargo test -p deepseek-tui --test js_execution_env_leak -- --nocapture:

use deepseek_tui::tools::js_execution::execute_js_execution_tool;
use serde_json::json;
use tempfile::tempdir;

#[tokio::test]
async fn js_execution_inherits_parent_secrets() {
    if deepseek_tui::dependencies::resolve_node().is_none() {
        eprintln!("node not on PATH; skipping");
        return;
    }
    unsafe {
        std::env::set_var("AWS_SECRET_ACCESS_KEY", "leak-marker-AKIA-EXAMPLE");
        std::env::set_var("DEEPSEEK_API_KEY", "leak-marker-sk-EXAMPLE");
    }
    let tmp = tempdir().unwrap();
    let result = execute_js_execution_tool(
        &json!({"code": "console.log(process.env.AWS_SECRET_ACCESS_KEY + '|' + process.env.DEEPSEEK_API_KEY)"}),
        tmp.path(),
    ).await.expect("execute");
    let payload: serde_json::Value = serde_json::from_str(&result.content).unwrap();
    let stdout = payload["stdout"].as_str().unwrap_or("");
    assert!(stdout.contains("leak-marker-AKIA-EXAMPLE"), "AWS leaked: {stdout}");
    assert!(stdout.contains("leak-marker-sk-EXAMPLE"), "DEEPSEEK leaked: {stdout}");
}

Equivalent reproducer against the binary:

export AWS_SECRET_ACCESS_KEY="leak-marker-AKIA-EXAMPLE"
export DEEPSEEK_API_KEY="leak-marker-sk-EXAMPLE"
deepseek
# Ask the model to run:
#   js_execution({"code":"console.log(JSON.stringify(process.env))"})
# Approve once. The returned stdout contains every parent env value verbatim,
# including the markers above, and is now part of the model's context for the next request.

The fix is one line added next to the existing cmd.current_dir(workspace) call:

let mut cmd = tokio::process::Command::new(&node);
cmd.arg(&script_path);
cmd.current_dir(workspace);
crate::child_env::apply_to_tokio_command(&mut cmd, std::iter::empty::<(&str, &str)>());

This calls the existing helper with no overrides, mirroring how repl/runtime.rs spawns the Python REPL. The behavior the description string already promises (sandbox) is then partially honored: secret-bearing parent variables stay in the parent.

Impact

The tool returns parent-environment secrets to the model on a single approval, or with no approval in YOLO mode. Any variable the user has exported becomes part of the next model request and travels to the configured LLM provider's logs. Common variables that the codebase's own provider clients read from process env, and therefore the values most likely to be present, include DEEPSEEK_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY, MISTRAL_API_KEY, AZURE_OPENAI_API_KEY, XAI_API_KEY, GROQ_API_KEY, and TOGETHER_API_KEY. Cloud and source-control credentials commonly exported in developer shells include AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, GOOGLE_APPLICATION_CREDENTIALS, GITHUB_TOKEN, GH_TOKEN, GITLAB_TOKEN, NPM_TOKEN, CARGO_REGISTRY_TOKEN, PYPI_API_TOKEN, and DATABASE_URL-style secrets. The local-sandbox wording shown at approval time understates the trust boundary, so users approving what they read as a sandboxed snippet do not anticipate that every shell-exported credential is reachable from the snippet. The remediation matches the pattern already adopted across exec_shell, the Python REPL, and the MCP launcher, so the gap is a missed call site rather than a design tradeoff.

CVE-2026-75915 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.8.41, 0.8.64); upgrading removes the vulnerable code path.

Affected versions

deepseek-tui (>= 0.8.32, <= 0.8.41) deepseek-tui (>= 0.8.32, < 0.8.41) codewhale-tui (>= 0.8.41, < 0.8.64) codewhale (>= 0.8.41, < 0.8.64)

Security releases

deepseek-tui → 0.8.41 (npm) codewhale-tui → 0.8.64 (rust) codewhale → 0.8.64 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade the following packages to resolve this vulnerability:

deepseek-tui to 0.8.41 or later; codewhale-tui to 0.8.64 or later; codewhale to 0.8.64 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-75915? CVE-2026-75915 is a high-severity security vulnerability in deepseek-tui (rust), affecting versions >= 0.8.32, <= 0.8.41. It is fixed in 0.8.41, 0.8.64.
  2. How severe is CVE-2026-75915? CVE-2026-75915 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which packages are affected by CVE-2026-75915?
    • deepseek-tui (rust) (versions >= 0.8.32, <= 0.8.41)
    • codewhale-tui (rust) (versions >= 0.8.41, < 0.8.64)
    • codewhale (npm) (versions >= 0.8.41, < 0.8.64)
  4. Is there a fix for CVE-2026-75915? Yes. CVE-2026-75915 is fixed in 0.8.41, 0.8.64. Upgrade to this version or later.
  5. Is CVE-2026-75915 exploitable, and should I be worried? Whether CVE-2026-75915 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-75915 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-75915?
    • Upgrade deepseek-tui to 0.8.41 or later
    • Upgrade codewhale-tui to 0.8.64 or later
    • Upgrade codewhale to 0.8.64 or later

Stop the waste.
Protect your environment with Kodem.