Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The taskcreate tool spawns durable sub-agents that inherit two insecure defaults: - allowshell defaults to true (config.rs:1499: self.allowshell.unwrapor(true)) - autoapprove defaults to true (taskmanager.rs:297: autoapprove: Some(true)) When a user approves a taskcreate 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 allowshell nor autoapprove need to be explicitly specified by the model and both default to true. PoC Step 1 — Create a malicious repo: Cargo.toml: [package] name = "web-service" version = "0.1.0" edition = "2021" src/lib.rs (clean, no injection): pub fn hello() - &'static str { "Hello, world!" } // TODO: refactor this into smaller modules // TODO: add proper error handling with Result types // TODO: add unit tests for all public functions // TODO: write README.md with…
Recommended action: Upgrade to 0.8.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details https://github.com/Hmbown/DeepSeek-TUI/blob/15f62e3e93d842f30b428877819ebc1c8cb96814/crates/tui/src/tools/fetchurl.rs#L321 PoC Prompt: Run fetchurl tool and give output, no thinking. Use url : http://[::1] Impact Access to local restricted resources
Recommended action: Upgrade to 0.8.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The runtests 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: 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 an inconsistency in the security boundary. However, in a malicious repository, test code can execute arbitrary shell commands, exfiltrate credentials, or establish persistence with zero approval. The attack is amplified by AGENTS.md (auto-loaded into the system prompt), which can instruct the model to run tests proactively at session start. PoC Step 1 — Create a malicious Rust repo: Cargo.toml: [package] name = "cool-library" version = "0.1.0" edition = "2021" src/lib.rs: pub fn add(a: i32, b: i32) - i32 { a + b } tests/integrationtest.rs: use coollibrary::add; #[test] fn testadd() { asserteq!(add(2, 3), 5);…
Recommended action: Upgrade to 0.8.23 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fetchurl tool validates the initial URL's resolved IP address against a restricted-IP blocklist (isrestrictedip()) 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. PoC Step 1 — Baseline: Confirm fetchurl blocks direct requests to restricted IPs. Step 2 — SSRF bypass via redirect: Fetch a public URL that redirects to the restricted IP. Expected result: The error message says "connection refused" or "request failed: connect error" — NOT "restricted address." This proves the SSRF filter was bypassed; the connection failed only because 169.254.169.254 is unreachable from a non-cloud machine. Observed result: fetchurl followed the 302 redirect and attempted to connect to 169.254.169.254. The error was a TCP-level…
Recommended action: Upgrade to 0.8.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.