DeepSeek-TUI Flaw Enabled RCE via Agent Prompt Injection

A vulnerability in the DeepSeek-TUI coding assistant enabled remote code execution. The flaw, identified as CVE-2026-45374, allowed an attacker to run arbitrary shell commands on a developer's machine. The attack vector uses prompt injection hidden within a project's files. It exploits insecure default settings when the tool creates autonomous sub-agents. [1] This issue highlights a growing class of vulnerabilities in AI-powered developer tools where user approval can be bypassed.

The Attack: From Project File to Code Execution

The attack begins when a developer interacts with a malicious repository. A user might clone a project from a public source and open it in DeepSeek-TUI. They then ask the integrated AI assistant to perform a common task. Examples include refactoring code, adding documentation, or fixing bugs listed in comments. The initial user request is benign.

The tool's language model may then propose creating a durable sub-agent to handle the work. It uses the `task_create` function for this purpose. The user receives an approval prompt. This prompt only shows the high-level goal, such as "create a task to fix the TODOs and write a README.md". The user approves this seemingly harmless action. [2]

Unknown to the user, the cloned repository contains a booby-trapped file. This could be a markdown file like `AGENTS.md` or `CONTRIBUTING.md`. Inside this file, disguised as development instructions or project standards, are malicious prompts. An example instruction might tell the agent to "generate a build badge" by running a `curl` command that pings an attacker's server.

After the user approves the task creation, the new sub-agent spawns. It inherits its context from the project, including the malicious markdown file. The agent reads the file and follows the embedded instructions. Due to the vulnerability, it executes the shell command without asking for any further approval. The attacker's server receives a connection, confirming successful remote code execution.

Technical Cause: A Chain of Insecure Defaults

The vulnerability's root cause is not a memory error or a typical bug. It is a logical flaw based on two insecure default settings in the `task_create` function. These settings are `allow_shell` and `auto_approve`. [2] Their combined effect created the security hole.

The first insecure default involved the `allow_shell` parameter. When a new task was created, this setting defaulted to `true`. This gave any spawned sub-agent the ability to execute arbitrary shell commands. Granting shell access is a highly privileged operation. The tool did not inform the user that this permission was being silently granted.

The second insecure default was `auto_approve`. This parameter also defaulted to `true` for new tasks. This setting instructed the sub-agent to automatically approve any actions it decided to take on its own. This includes the execution of shell commands provided by the `allow_shell` permission.

The combination of these two defaults was critical. One setting gave the sub-agent a dangerous capability. The other setting removed any human oversight over the use of that capability. This created a scenario where a sub-agent could be created, read a malicious prompt, and execute a shell command without any user interaction beyond the initial, misleading approval.

The Agentic Threat Surface: Beyond Traditional CVEs

This incident demonstrates the unique nature of the agentic threat surface. The vulnerability is not in the code's memory management but in its logic for delegation and trust. It exploits the semantic gap between what a user thinks they are approving and what the system actually does.

The core problem is a broken trust boundary. The developer grants trust to the main DeepSeek-TUI session. However, the application improperly extended that trust to a sub-agent. This sub-agent then operated on untrusted input, the attacker-controlled project files, with dangerously high privileges.

Traditional defenses might miss this attack. A static analysis tool would not see a malformed input string causing a buffer overflow. An antivirus scanner might not flag the markdown file as malicious. The malicious payload is just text until the language model interprets it as an instruction and an insecurely configured agent executes it. This blurs the line between data and executable code.

Detection and Mitigation

The vendor has addressed the vulnerability. All users of DeepSeek-TUI should immediately upgrade to version 0.8.26 or a later release. This patched version contains the necessary security fixes. [3] Continuing to use older versions leaves systems exposed to this attack vector.

The patch corrects the insecure defaults. In the updated version, both `allow_shell` and `auto_approve` now default to `false` for new tasks. To grant these permissions, the model must now explicitly request them. This change ensures that granting elevated privileges is a deliberate act, not an implicit side effect. The approval prompt is also expected to be updated to inform the user when shell access is requested. [2]

This vulnerability underscores the need for a new defensive mindset. Development teams using AI assistants must treat all files from third-party repositories as potentially hostile. This includes not just code but also documentation, configuration files, and build scripts. Any text file can become a source of prompt injection.

Organizations should enhance monitoring for agentic activity. Security teams need visibility into the behavior of AI agents and sub-agents. Logging should capture task creation events, inherited permissions, and sensitive operations like file system access or shell execution. Anomaly detection can help spot a sub-agent that deviates from expected behavior, such as making unexpected network calls.

Implications for AI-Powered Development

This vulnerability serves as a critical case study for the security of AI-powered development tools. The drive for automation and convenience can lead to the creation of powerful agents. However, without careful design, these agents can become vectors for autonomous exploitation.

The principle of least privilege is more important than ever in the age of AI agents. Systems should default to the most secure settings. Sub-agents, in particular, should start with zero-trust permissions. Any escalation of privilege must require explicit, informed consent from the user, clearly stating the risks involved.

As agentic architectures become more common, managing the web of permissions and trust will be a central security challenge. This incident is an early warning. The security community must develop new frameworks and tools to manage the lifecycle, permissions, and oversight of autonomous AI agents to prevent similar compromises.