GHSA-WRJ3-VJ8C-784F
Vulnerability from github – Published: 2026-09-04 18:12 – Updated: 2026-09-04 18:12Maintainer 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
The rlm_eval tool runs an arbitrary Python string chosen by the model in a real python3 interpreter. Its approval_requirement() returns ApprovalRequirement::Auto, which the engine treats as "never prompt," regardless of the user's configured --approval-policy. A single tool call — which prompt injection from any untrusted content the agent reads (a web page, a fetched URL, a repo file, an MCP tool result) can induce — runs code on the user's machine at the user's privilege with no prompt and no audit step. This is the same defect that was already patched on the sibling run_tests tool (CVE-2026-45311); the fix never reached rlm_eval or rlm_open, which expose a broader surface (full Python on the host, not just cargo test).
Details
rlm_eval's execute() reads the LLM-controlled code field and runs it (crates/tui/src/tools/rlm.rs:215-300):
fn capabilities(&self) -> Vec<ToolCapability> {
vec![ToolCapability::Network, ToolCapability::ExecutesCode]
}
fn approval_requirement(&self) -> ApprovalRequirement {
ApprovalRequirement::Auto // overrides the safe default below
}
async fn execute(&self, input: Value, context: &ToolContext) -> Result<ToolResult, ToolError> {
let name = required_non_empty_str(&input, "name")?;
let code = required_non_empty_str(&input, "code")?; // LLM-controlled
...
let round = kernel.run(code, Some(&bridge)).await... // runs that code in python3
The trait default at crates/tui/src/tools/spec.rs:632-633 would have returned Required for any tool whose capabilities include ExecutesCode. rlm_eval deliberately overrides that to Auto.
The engine's approval gate (crates/tui/src/core/engine.rs:845) is two AND-ed conditions, and a per-tool Auto makes the first one false:
let approval_required = spec.approval_requirement() != ApprovalRequirement::Auto
&& !registry.context().auto_approve;
When approval_requirement() is Auto, approval_required is false, no Event::ApprovalRequired is emitted, and the user's --approval-policy (on-request, unless-trusted, never) is never consulted. The companion tool rlm_open (rlm.rs:142-143, same Auto, capabilities include ExecutesCode + Network) spawns the same Python kernel via PythonRuntime::spawn_with_context (rlm.rs:181) and can stage a content string, a file_path read, or a url fetch into the kernel before rlm_eval runs against it. Both tools are registered unconditionally by the default registry (crates/tui/src/tools/registry.rs:802-803); there is no flag to disable them.
PoC
Source-level reproduction. Point a provider's base_url at a local mock that returns canned tool_calls, then have the agent call rlm_open followed by rlm_eval with a code payload such as:
import os, getpass, socket
open('/tmp/pwned_by_rlm_eval','w').write(getpass.getuser()+'@'+socket.gethostname()+':'+os.getcwd())
Run it through the non-interactive path (codewhale exec --auto) to confirm the tool executes, and through the plain interactive TUI under --approval-policy on-request (no --auto, no --yolo) to confirm no approval dialog appears. The sentinel file is written either way; the interactive run is the one that proves the policy is bypassed rather than waived.
Impact
Unsandboxed code execution on the user's workstation at the user's UID: read SSH keys, cloud credentials, ~/.codewhale/auth.json, and other secrets; write to shell rc files or authorized_keys for persistence; spawn subprocesses; reach the network. No filesystem, network, or process sandbox is applied to the spawned interpreter. Reachable with user interaction (running the agent over attacker-influenced content), no further prompt.
Credit
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "deepseek-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.33"
},
{
"last_affected": "0.8.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "deepseek-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.33"
},
{
"fixed": "0.8.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "codewhale-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.41"
},
{
"fixed": "0.8.64"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "codewhale"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.41"
},
{
"fixed": "0.8.64"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-75858"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-04T18:12:15Z",
"nvd_published_at": "2026-08-18T16:18:21Z",
"severity": "HIGH"
},
"details": "### Maintainer resolution\n\nThe 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.\n\n### Summary\nThe `rlm_eval` tool runs an arbitrary Python string chosen by the model in a real `python3` interpreter. Its `approval_requirement()` returns `ApprovalRequirement::Auto`, which the engine treats as \"never prompt,\" regardless of the user\u0027s configured `--approval-policy`. A single tool call \u2014 which prompt injection from any untrusted content the agent reads (a web page, a fetched URL, a repo file, an MCP tool result) can induce \u2014 runs code on the user\u0027s machine at the user\u0027s privilege with no prompt and no audit step. This is the same defect that was already patched on the sibling `run_tests` tool (CVE-2026-45311); the fix never reached `rlm_eval` or `rlm_open`, which expose a broader surface (full Python on the host, not just `cargo test`).\n\n### Details\n`rlm_eval`\u0027s `execute()` reads the LLM-controlled `code` field and runs it (`crates/tui/src/tools/rlm.rs:215-300`):\n\n```rust\nfn capabilities(\u0026self) -\u003e Vec\u003cToolCapability\u003e {\n vec![ToolCapability::Network, ToolCapability::ExecutesCode]\n}\n\nfn approval_requirement(\u0026self) -\u003e ApprovalRequirement {\n ApprovalRequirement::Auto // overrides the safe default below\n}\n\nasync fn execute(\u0026self, input: Value, context: \u0026ToolContext) -\u003e Result\u003cToolResult, ToolError\u003e {\n let name = required_non_empty_str(\u0026input, \"name\")?;\n let code = required_non_empty_str(\u0026input, \"code\")?; // LLM-controlled\n ...\n let round = kernel.run(code, Some(\u0026bridge)).await... // runs that code in python3\n```\n\nThe trait default at `crates/tui/src/tools/spec.rs:632-633` would have returned `Required` for any tool whose capabilities include `ExecutesCode`. `rlm_eval` deliberately overrides that to `Auto`.\n\nThe engine\u0027s approval gate (`crates/tui/src/core/engine.rs:845`) is two AND-ed conditions, and a per-tool `Auto` makes the first one false:\n\n```rust\nlet approval_required = spec.approval_requirement() != ApprovalRequirement::Auto\n \u0026\u0026 !registry.context().auto_approve;\n```\n\nWhen `approval_requirement()` is `Auto`, `approval_required` is `false`, no `Event::ApprovalRequired` is emitted, and the user\u0027s `--approval-policy` (`on-request`, `unless-trusted`, `never`) is never consulted. The companion tool `rlm_open` (`rlm.rs:142-143`, same `Auto`, capabilities include `ExecutesCode` + `Network`) spawns the same Python kernel via `PythonRuntime::spawn_with_context` (`rlm.rs:181`) and can stage a `content` string, a `file_path` read, or a `url` fetch into the kernel before `rlm_eval` runs against it. Both tools are registered unconditionally by the default registry (`crates/tui/src/tools/registry.rs:802-803`); there is no flag to disable them.\n\n### PoC\nSource-level reproduction. Point a provider\u0027s `base_url` at a local mock that returns canned `tool_calls`, then have the agent call `rlm_open` followed by `rlm_eval` with a `code` payload such as:\n\n```python\nimport os, getpass, socket\nopen(\u0027/tmp/pwned_by_rlm_eval\u0027,\u0027w\u0027).write(getpass.getuser()+\u0027@\u0027+socket.gethostname()+\u0027:\u0027+os.getcwd())\n```\n\nRun it through the non-interactive path (`codewhale exec --auto`) to confirm the tool executes, and through the plain interactive TUI under `--approval-policy on-request` (no `--auto`, no `--yolo`) to confirm no approval dialog appears. The sentinel file is written either way; the interactive run is the one that proves the policy is bypassed rather than waived.\n\n### Impact\nUnsandboxed code execution on the user\u0027s workstation at the user\u0027s UID: read SSH keys, cloud credentials, `~/.codewhale/auth.json`, and other secrets; write to shell rc files or `authorized_keys` for persistence; spawn subprocesses; reach the network. No filesystem, network, or process sandbox is applied to the spawned interpreter. Reachable with user interaction (running the agent over attacker-influenced content), no further prompt.\n\n### Credit\n[sai-sh](https://github.com/sai-sh)",
"id": "GHSA-wrj3-vj8c-784f",
"modified": "2026-09-04T18:12:15Z",
"published": "2026-09-04T18:12:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Hmbown/CodeWhale/security/advisories/GHSA-wrj3-vj8c-784f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75858"
},
{
"type": "WEB",
"url": "https://github.com/Hmbown/CodeWhale/commit/57f3c89471e27ac4032d9791f6885e5d4408c381"
},
{
"type": "PACKAGE",
"url": "https://github.com/Hmbown/CodeWhale"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/codewhale-rlm-eval-before-remote-code-execution"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "CodeWhale: rlm_eval auto-approves arbitrary Python execution, bypassing the user\u0027s approval policy (RCE)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.