T08 · Insecure Dependencies
- Location
SKILL.md:34- Finding
Unpinned Third-Party Packages Are Installed and Executed
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:34-36andSKILL.md:67-68
Vulnerability Type: T08: Insecure Dependencies
Risk Level: MediumThe Skill instructs users to retrieve mutable third-party packages from external registries without version pins, hashes, lockfiles, or provenance verification. It then directs users to execute binaries installed by one of those packages.
bash pip install ollama-herd # Self-hosted AI router from PyPI herd # start the self-hosted router herd-node # run on each self-hosted machine — auto-discovers the routerAdditional unpinned packages are installed for image-generation functionality:
bash uv tool install mflux # Self-hosted Flux models (~7s) uv tool install diffusionkit # Self-hosted Stable Diffusion 3/3.5Technical Analysis
Package names without exact versions resolve to whatever release the external registry serves at installation time. Consequently, the code users execute can change after the Skill has been reviewed. Package installation may also execute package build hooks or install transitive dependencies, while the subsequent
herdandherd-nodecommands directly execute newly downloaded code.This creates a software supply-chain risk. Compromise of a package publisher account, registry entry, release process, or transitive dependency could replace an expected package with attacker-controlled code. The documentation provides no hash verification, signed-release validation, dependency lockfile, or reviewed version constraint to detect such a substitution.
Installing dependencies is relevant to the declared self-hosted AI functionality, so the behavior is not inherently malicious. However, immediately installing and executing mutable remote packages exceeds what is necessary for merely documenting or querying the local API and lacks reasonable integrity controls.
The commands at `SK ...[truncated 2166 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin every directly installed package to a reviewed, exact version, for example
ollama-herd==X.Y.Z, and document a controlled update process. - Provide cryptographic hashes through a hash-locked requirements file or an equivalent package-manager lockfile, and require hash verification during installation.
- Pin and review transitive dependencies rather than relying only on top-level version constraints.
- Link to the official registry records and signed source releases so users can verify package provenance and publisher identity.
- Recommend installation in an isolated virtual environment or dedicated tool environment under an unprivileged account.
- Separate installation from execution and instruct users to inspect package metadata, signatures, hashes, and release notes before launching newly installed binaries.
- Pin
mfluxanddiffusionkitversions and apply the same integrity verification used forollama-herd. - Document the ports, local-network discovery behavior, filesystem paths, and network permissions required by
herdandherd-node, allowing users to restrict execution to the minimum necessary access. - Avoid administrator or root installation and execution unless a specifically documented feature strictly requires it.
- Pin every directly installed package to a reviewed, exact version, for example
