CVE-2026-75911 in CodeWhale
Summary
by MITRE • 08/18/2026
CodeWhale versions before 0.8.64 fail to properly validate the allow_shell configuration parameter from project config files, allowing attackers to enable arbitrary shell command execution by committing a malicious .codewhale/config.toml file to a repository. When a user clones and opens the repository in CodeWhale, the AI model gains access to exec_shell and task_shell tools, enabling execution of arbitrary shell commands on the victim's machine without explicit user consent.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in CodeWhale versions prior to 0.8.64 represents a critical security flaw rooted in improper input validation within the application configuration handling mechanism. Specifically, the software fails to adequately sanitize or validate the allow_shell parameter when it is sourced from project-specific configuration files such as .codewhale/config.toml. This oversight allows an attacker who has write access to a repository to inject malicious configuration directives that override default security settings. By committing a specially crafted config file containing set_allow_shell = true, an adversary can effectively bypass the application's intended restrictions on shell execution capabilities without requiring any direct interaction or consent from the end user during the initial setup phase.
When a victim clones and opens this compromised repository within their local instance of CodeWhale, the application reads the malicious configuration file as part of its standard initialization process. Because the validation logic is insufficient, the software accepts the allow_shell directive at face value, thereby enabling the exec_shell and task_shell tools for the AI model associated with that project context. This transition fundamentally alters the trust boundary between the user and the artificial intelligence agent. The AI model, which may be processing benign or malicious prompts provided by other users or automated systems within the repository's workflow, gains unrestricted access to execute arbitrary shell commands on the victim's operating system.
The operational impact of this vulnerability is severe, as it facilitates remote code execution through a social engineering vector disguised as legitimate project configuration. An attacker does not need to exploit a traditional software bug in the binary or network stack; instead, they leverage the trust users place in repository contents and the convenience features of AI-assisted development tools. Once enabled, the shell access allows for data exfiltration, installation of persistent backdoors, lateral movement within internal networks if connected systems are accessible via command line, or complete compromise of the local workstation environment. This is particularly dangerous because the execution occurs silently in the background as part of normal IDE operations, making detection difficult without specialized monitoring tools that inspect AI agent behavior and system call patterns.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, specifically regarding the failure to verify configuration parameters against expected safe values before enabling privileged features. It also relates closely to CWE-94 Code Injection, as the shell execution capability is effectively injected into the AI agent's operational scope through malicious configuration data rather than direct code injection. In terms of adversary tactics, this scenario maps directly to MITRE ATT&CK technique T1059 Command and Scripting Interpreter, where an attacker uses system utilities like bash or cmd.exe to execute commands. Furthermore, it reflects aspects of T1620 Reflective Code Loading if the shell commands are used to load additional payloads into memory, although in this specific instance, the primary vector is configuration-based privilege escalation for AI agents.
Mitigation strategies must focus on both immediate patching and long-term architectural changes. The most urgent action is to upgrade all instances of CodeWhale to version 0.8.64 or later, where the validation logic for the allow_shell parameter has been corrected to enforce strict defaults that require explicit user confirmation before enabling shell access. Organizations should also implement configuration management policies that restrict which users can modify project-level config files in shared repositories. Additionally, security teams should deploy endpoint detection and response solutions capable of monitoring for unusual processes spawned by IDEs or AI agents, particularly those involving command-line interpreters launched without direct user initiation. Enabling audit logs for shell execution events within the development environment will also aid in detecting any potential exploitation attempts that may have occurred prior to patching.