Advisories for Cargo/Deepseek-Tui package

The task_create tool spawns durable sub-agents that inherit two insecure defaults: allow_shell defaults to true (config.rs:1499: self.allow_shell.unwrap_or(true)) auto_approve defaults to true (task_manager.rs:297: auto_approve: Some(true)) When a user approves a task_create call (which requires ApprovalRequirement::Required), they approve what appears to be a benign work prompt (e.g., "fix TODOs and write a README"). However, the spawned sub-agent silently receives unrestricted, unapproved shell access. Neither allow_shell nor auto_approve need to be explicitly specified …

The run_tests tool executes cargo test in the workspace with ApprovalRequirement::Auto, meaning it runs without any user approval prompt. The source code explicitly states this design choice: fn approval_requirement(&self) -> ApprovalRequirement { // Tests are encouraged, so avoid gating them behind approval. ApprovalRequirement::Auto } cargo test compiles and executes arbitrary code: test binaries, build.rs build scripts, and proc macros. While auto-approving test execution is a deliberate design choice, it creates …

The fetch_url tool validates the initial URL's resolved IP address against a restricted-IP blocklist (is_restricted_ip()) to prevent SSRF attacks against internal services (cloud metadata endpoints, localhost, private networks). However, the HTTP client (reqwest) is configured to automatically follow up to 5 redirects (reqwest::redirect::Policy::limited(5)) without re-validating the redirect target against the same SSRF protections.

Although SSRF is validated against hostnames that resolve to private IPv6 addresses, when providing the IPV6 in‌‌ URL‌ as http://[::1], the SSRF defenses do not work.