GitHub updated its advisory database record for CVE-2026-75911 on 4 September 2026 after the CodeWhale maintainer advisory was first published on 16 July. The configuration flaw could let a cloned repository silently enable shell tools for the AI coding agent. The advisory records CodeWhale and codewhale-tui versions from 0.8.41 up to, but not including, 0.8.64 as affected. Version 0.8.64 contains the fix.
The flaw is not a remote compromise of every CodeWhale installation. Exploitation requires a user to clone or open a malicious or compromised repository and then run CodeWhale in that workspace. The security consequence is still significant because a project-controlled file could expand the tool surface without the user's explicit opt-in.
A project file could enable the shell boundary
CodeWhale reads .codewhale/config.toml or .deepseek/config.toml from a project. According to the maintainer advisory, a repository could set allow_shell = true. The merge logic accepted that value and added shell tools to the model's tool registry.
Other settings, including the approval policy and sandbox mode, already used tightening-only guards. A project could make those controls more restrictive but could not silently relax them. The allow_shell value did not have the equivalent guard. The patch makes project scope unable to turn shell access on.
The advisory assigns a CVSS 3.1 score of 7.8 and rates the issue High. It describes a local attack vector, low complexity, no attacker privileges on the victim system, required user interaction, and high potential impact to confidentiality, integrity, and availability. Those ratings describe a scenario and should not be treated as proof that exploitation occurred.
GitLab's advisory database lists the same affected and fixed ranges and recommends upgrading to 0.8.64 or later. The independent listing corroborates the package metadata and patch level. It does not establish active exploitation, affected-user counts, or the success rate of the proof of concept.
Repository trust is part of the agent security model
Developers often treat repository files as code to review, but an AI coding agent may also interpret them as instructions, tool configuration, hooks, or policy. That creates a second execution surface before the application itself is built.
A safe precedence model should distinguish who may reduce authority from who may grant it:
| Configuration source | Safe default |
|---|---|
| Repository or workspace | May tighten permissions, never silently expand them |
| User profile | May define explicit personal defaults |
| Organization policy | May set enforceable maximum authority |
| Command-line override | Requires visible, deliberate user action |
| Runtime model output | Cannot change its own tool permissions |
Maetra's prompt injection controls for AI agents explains why untrusted instructions need separation from authority. The runtime controls guide covers tool permissions, identity, inspection, and effect evidence around consequential actions.
Upgrade first, then inspect the trust chain
Teams using an affected version should upgrade to 0.8.64 or later. They should also review cloned repositories for CodeWhale and DeepSeek project configuration, confirm how shell tools were enabled in previous sessions, and rotate credentials if there is evidence that an untrusted workspace ran commands.
An investigation should preserve the repository commit, configuration hash, effective merged settings, tool registry, model session, shell commands, process results, file changes, network effects, and human approvals. Merely deleting the project file removes useful evidence and does not show whether an effect occurred.
Controls should be tested with negative cases. A project file that requests more authority should be ignored or rejected. The user should see a clear warning. An organization-level restriction should remain effective after project merges, restarts, and command-line changes. Logs should record the effective policy without storing secrets.
What remains uncertain
The public advisory does not claim active exploitation. It does not provide affected-installation counts or evidence that a particular command was executed in the wild. The proof describes how the setting reaches the tool registry, but the final effect still depends on the model output, command classification, user context, operating-system permissions, and available credentials.
Package ranges also differ for the older deepseek-tui names listed in the advisory. Teams should use the exact ecosystem and package entry relevant to their installation rather than assuming one version number covers every artifact.
Maetra analysis
The important design principle is monotonic authority. Lower-trust configuration may remove permissions, demand more review, or reduce scope. It should not be able to grant a tool, identity, credential, or execution mode that a higher-trust layer did not already authorize.
This rule needs effect verification as well as configuration validation. An agent can retain a safe-looking policy while a separate hook, plugin, environment variable, or wrapper opens another route to the shell. Inventory the complete tool surface, calculate the effective policy after every merge, and test the actual downstream effects.
CVE-2026-75911 is a focused flaw with a released patch. Its wider lesson applies to every coding agent that consumes repository-controlled configuration: the workspace is input, not authority.