T08 · Insecure Dependencies
- Location
SKILL.md:15- Finding
Unpinned Third-Party Package Is Downloaded and Executed Through uvx
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 15-27
Vulnerability Type: Unpinned dependency execution
Risk Level: MediumVulnerable Code
markdown ## What are the requirements? - `uv` installed (for `uvx`) - `HF_TOKEN` env var or `--hf-token` flag (for gated or private models only) ## How to run? Run with `--model-id` pointing to the Hugging Face Hub repository which will check that it either contains Safetensors (via `model.safetensors`, `model.safetensors.index.json` if sharded, or `model_index.json` for Diffusers) or GGUF model weights within. ```bash uvx hf-mem --model-id <model-id> --json-outputtext Equivalent unpinned `uvx hf-mem` commands also occur throughout lines 34-79. ### Technical Analysis The Skill instructs the agent to use `uvx` to resolve, download, and execute the third-party `hf-mem` package without specifying an audited version, package hash, lockfile, or verified source. Consequently, the code executed at runtime is not fully represented by the reviewed Skill and can change independently after the audit. This creates a software supply-chain exposure. If the package publisher account, package registry, package distribution process, or a future package release is compromised, an attacker-controlled package could execute automatically when the documented command is invoked. The risk is heightened because the documentation identifies `HF_TOKEN` as an environment variable that may be present during execution. The reviewed `SKILL.md` itself contains no embedded executable payload, obfuscated code, persistence mechanism, or explicit credential-exfiltration instruction. Exploitation depends on compromise or malicious replacement of the externally resolved dependency. ### Attack Path 1. An attacker compromises the package publisher, registry entry, or distribution channel used to resolve `hf-mem`, or publishes a malicious version through an applicable packa ...[truncated 1292 chars]- Remediation
View remediation
Remediation Suggestions
- Pin
hf-memto a specific, reviewed version in every documented invocation rather than resolving the latest available release. - Use a lockfile or equivalent dependency manifest that records exact transitive dependency versions.
- Require cryptographic hash verification or signed-artifact verification for the package and its dependencies.
- Document the expected package registry and verified publisher identity to reduce dependency-confusion and package-spoofing risks.
- Review new package versions before updating the pin, including changes to transitive dependencies.
- Execute the package in a sandbox or container with minimal filesystem permissions and restricted outbound network access.
- Provide only the minimum required Hugging Face token scope and avoid exposing unrelated secrets to the process.
- Prefer protected environment-based secret injection over command-line token arguments, which may be exposed through process listings, shell history, or logs.
- Where feasible, maintain a locally reviewed implementation or an internally mirrored and integrity-verified package artifact.
- Pin
