T08 · Insecure Dependencies
Warning
- Location
- references/setup.md:37
- Finding
- Unpinned Third-Party CLI Installation Creates a Supply-Chain Risk## Vulnerability Details **File Location**: `SKILL.md:16-19`; `references/setup.md:37-53` **Vulnerability Type**: Unpinned and mutable third-party executable installation **Risk Level**: Medium The skill directs users to install the external `yutu` CLI without pinning an audited version or requiring artifact integrity verification. **Relevant code from `SKILL.md:16-19`:** ```yaml install: - kind: node package: "@eat-pray-ai/yutu" bins: [yutu] ``` **Relevant code from `references/setup.md:37-53`:** ```bash # Node.js (all platforms) npm i -g @eat-pray-ai/yutu # macOS brew install yutu # Linux brew install yutu # Windows winget install yutu # Gopher go install github.com/eat-pray-ai/yutu@latest ``` ```text Download a prebuilt binary from the releases page and place it in your PATH. ``` ### Technical Analysis The installation declarations and setup instructions resolve mutable upstream package or release versions. In particular, the Go command explicitly requests `@latest`, while the npm, Homebrew, WinGet, and release-page instructions do not specify an audited version or require checksum or signature validation. This creates a supply-chain trust boundary that is not controlled by the skill package. If an upstream publisher account, package registry entry, repository release, package-manager formula, or distribution artifact is compromised, users following these instructions may receive code different from the code originally reviewed. The risk is elevated because the installed CLI is subsequently entrusted with OAuth client credentials and a cached YouTube OAuth token through `client_secret.json`, `youtube.token.json`, `YUTU_CREDENTIAL`, and `YUTU_CACHE_TOKEN`. There is no evidence in the reviewed project that the current upstream package is malicious; exploitation depends on compromise or malicious replacement of a mutable upstream artifact. ### Attack Path 1. An attacker c ...[truncated 1574 chars]
- Remediation
- ## Remediation Suggestions 1. Pin every installation method to a specific, reviewed version rather than using implicit latest versions or `@latest`. 2. For Go installations, use an explicit immutable version such as `github.com/eat-pray-ai/yutu@vX.Y.Z`. 3. For npm, document an exact package version and consider using a project-local installation with a lockfile instead of an unrestricted global installation. 4. Publish and verify cryptographic checksums for downloaded binaries. Prefer signed releases and document signature verification commands. 5. Record the expected package publisher, repository, release version, and artifact digest so users can detect dependency confusion or substituted artifacts. 6. Avoid administrative installation or execution unless strictly necessary; run the CLI with least privilege. 7. Request only the minimum OAuth scopes needed for search operations, and document how users can inspect and revoke access. 8. Store OAuth token and client-secret files with restrictive filesystem permissions and keep them outside shared or version-controlled directories. 9. Establish a dependency update process in which new versions are reviewed and their pinned versions and hashes are updated deliberately.