GHSA-wrj3-vj8c-784f: Code Injection

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 The rlmeval tool runs an arbitrary Python string chosen by the model in a real python3 interpreter. Its approvalrequirement() 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 runtests tool (CVE-2026-45311); the fix never reached rlmeval or rlmopen, which expose a broader surface (full Python on the host, not just cargo test).

Details rlmeval's execute() reads the LLM-controlled code field and runs it (crates/tui/src/tools/rlm.rs:215-300):

rust fn capabilities(&self) -> Vec<ToolCapability> { vec![ToolCapability::Network, ToolCapability::ExecutesCode] }

fn approvalrequirement(&self) -> ApprovalRequirement { ApprovalRequirement::Auto // overrides the safe default below }

async fn execute(&self, input: Value, context: &ToolContext) -> Result<ToolResult, ToolError> { let name = requirednonemptystr(&input, "name")?; let code = requirednonemptystr(&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. rlmeval 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:

rust let approvalrequired = spec.approvalrequirement() != ApprovalRequirement::Auto && !registry.context().autoapprove;

When approvalrequirement() is Auto, approvalrequired is false, no Event::ApprovalRequired is emitted, and the user's --approval-policy (on-request, unless-trusted, never) is never consulted. The companion tool rlmopen (rlm.rs:142-143, same Auto, capabilities include ExecutesCode + Network) spawns the same Python kernel via PythonRuntime::spawnwithcontext (rlm.rs:181) and can stage a content string, a filepath read, or a url fetch into the kernel before rlmeval 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 baseurl at a local mock that returns canned toolcalls, then have the agent call rlmopen followed by rlmeval with a code payload such as:

python import os, getpass, socket open('/tmp/pwnedbyrlmeval','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 authorizedkeys 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 sai-sh