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
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.