CVE-2026-75858: Silent Remote Code Execution via Approval Bypass in CodeWhale Interactive Tools

CodeWhale is an artificial intelligence (AI) agent workspace framework designed to assist software developers by executing tasks locally. The system operates on an orchestration model where an LLM parses developer directives and determines which tools to execute. These tools have high-privilege access, including file system read/write, network access, and direct code execution capabilities on the host. To mitigate the risk of arbitrary code execution, the framework exposes a configurable security policy called --approval-policy intended to intercept high-risk actions.\n\nThe fundamental attack surface is exposed through tools like rlm_eval (used for Python evaluation) and exec_shell_interact (used for interactive shell executions). Because these tools execute instructions directly on the local host, they rely entirely on the engine's approval-prompting mechanism for safety. If an attacker can bypass this prompt, they gain immediate and unauthenticated execution of arbitrary commands under the privileges of the local system user.\n\nCVE-2026-75858 represents a logical flaw within the CodeWhale execution engine's approval gate. The vulnerability allows high-risk tools to flag themselves as auto-approving, which the core engine incorrectly interprets as a complete exemption from manual user consent. This defect completely nullifies the security guarantees provided by the --approval-policy parameter, enabling silent compromise of developer workstations via indirect prompt injection vectors.

The root cause of this vulnerability lies in the logical evaluation used by the CodeWhale tool execution engine to determine if user consent is required. Specifically, the engine uses the following evaluation to set the boolean variable approval_required:\n\napproval_required = spec.approval_requirement() != ApprovalRequirement::Auto && !registry.context().auto_approve;\n\nUnder this formulation, if a tool's internal specification defines its approval requirement as ApprovalRequirement::Auto, the first term spec.approval_requirement() != ApprovalRequirement::Auto evaluates to false. Because of the short-circuit behavior of the logical AND (&&) operator, the entire expression resolves to false, regardless of the user's globally configured auto-approval context state or --approval-policy.\n\nThis logic represents an inversion of secure-by-default design principles. An "Auto" approval requirement should mean that the engine evaluates the context dynamically to determine if consent is required. Instead, the engine treats ApprovalRequirement::Auto as an absolute exemption from manual authorization. This allows any tool designed with ApprovalRequirement::Auto to execute commands on the host without presenting a confirmation dialog to the developer.

To understand the vulnerability, we analyze the implementation of the RlmEvalTool and ShellInteractTool prior to the fix. Both tools incorrectly implemented the ToolSpec trait by returning ApprovalRequirement::Auto.\n\nIn crates/tui/src/tools/rlm.rs (vulnerable):\nrust\nimpl ToolSpec for RlmEvalTool {\n fn capabilities(&self) -> Vec<ToolCapability> {\n vec![ToolCapability::Network, ToolCapability::ExecutesCode]\n }\n\n fn approval_requirement(&self) -> ApprovalRequirement {\n ApprovalRequirement::Auto // Critical logical flaw\n }\n}\n\n\nThis implementation declares the capability ExecutesCode but overrides the approval requirement to Auto. The patch in commit 57f3c89471e27ac4032d9791f6885e5d4408c381 updates both tools to enforce explicit user consent.\n\nIn crates/tui/src/tools/rlm.rs (patched):\nrust\nimpl ToolSpec for RlmEvalTool {\n fn capabilities(&self) -> Vec<ToolCapability> {\n vec![\n ToolCapability::Network,\n ToolCapability::ExecutesCode,\n ToolCapability::RequiresApproval, // Explicitly declared capability\n ]\n }\n\n fn approval_requirement(&self) -> ApprovalRequirement {\n ApprovalRequirement::Required // Changed to force user prompt\n }\n}\n\n\nWhile this patch successfully remediates the direct exploitation vector in the default toolset, it does not rewrite the underlying engine logic. The fragile boolean expression in the execution engine remains unchanged, meaning any future custom tool that declares ApprovalRequirement::Auto will still bypass approval. A complete fix should have refactored the engine logic to default to Required unless explicitly disabled by a trusted administrative policy.

The primary attack vector for CVE-2026-75858 is Indirect Prompt Injection. Because the execution agent routinely interacts with remote, untrusted resources like public repositories or web pages, an attacker can embed malicious instructions within these inputs.\n\nWhen the developer commands CodeWhale to process a poisoned source, such as analyzing a file using rlm_open, the agent retrieves the file. The file contains a hidden system instruction directed at the LLM backend. The LLM parses these instructions as valid operating directives and generates a tool call to rlm_eval or exec_shell_interact containing the attacker's payload.\n\nmermaid\ngraph LR\n A[\"Attacker Resource\"] -->|\"Poisoned File\"| B[\"CodeWhale Agent\"]\n B -->|\"Parses Payload\"| C[\"LLM Orchestrator\"]\n C -->|\"Calls rlm_eval\"| D[\"Tool Engine\"]\n D -->|\"Bypasses Approval\"| E[\"Host OS Execution\"]\n\n\nThe execution occurs silently. Because the tool engine bypasses the confirmation screen, the agent directly invokes Python or Bash to run the malicious payload. This allows the attacker to execute arbitrary shell commands, such as downloading and executing a reverse shell payload, without triggering any visual alerts on the user's terminal interface.

The impact of successful exploitation is complete system compromise. The CodeWhale agent runs within the context of the local developer's user account, meaning the executed payload inherits the exact permissions, SSH keys, cloud credentials, and local environment variables of that developer.\n\nThis vulnerability is highly severe because of its utility in supply chain attacks. Attackers targeting a specific organization can place poisoned README files or code comments in public repositories. When a developer at the target organization uses CodeWhale to audit or review the repository, the attack triggers automatically, compromising the developer's workstation and providing a foothold into the enterprise network.\n\nFrom a threat perspective, this vulnerability maps to CVSS 3.1 score 7.8 and CVSS 4.0 score 8.5. The low complexity and lack of required privileges, combined with high confidentiality, integrity, and availability impacts, make it a valuable target for sophisticated threat actors attempting lateral movement or data exfiltration.

To remediate CVE-2026-75858, users must update their local installations of the codewhale and codewhale-tui crates to version 0.8.64 or higher. Running cargo update -p codewhale-tui updates the dependencies and incorporates the patch that replaces ApprovalRequirement::Auto with ApprovalRequirement::Required.\n\nIn environments where updating is delayed, organizations should restrict the network capabilities of CodeWhale. Preventing the agent from making outbound connections to untrusted web services reduces the likelihood of indirect prompt injections. Workspaces should be run inside isolated sandboxes, such as Docker containers or lightweight virtual machines, to limit the blast radius of any successful execution.\n\nDetection can be achieved by monitoring host-level process creation. Security teams should deploy eBPF or Auditd configurations to track the process tree of the CodeWhale binary. Any child processes spawned by CodeWhale (such as python3, bash, curl, or wget) that match abnormal command patterns should trigger immediate security alerts.