T08 · Insecure Dependencies
Error
- Location
- scripts/setup.sh:5
- Finding
- Unpinned Global Installation of Third-Party CLI Packages<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup.sh:5-8` **Additional Locations**: `package.json:9-15`, `SKILL.md:12-14`, `SKILL.md:94`, `README.md:20-23` **Vulnerability Type**: Unpinned and insufficiently verified third-party dependencies **Risk Level**: High ### Vulnerable Code ```bash if ! command -v molt &> /dev/null; then echo "Installing molt CLI..." npm install -g molt-cli 2>/dev/null || npm install -g moltunes-cli 2>/dev/null fi ``` Related package configuration: ```json "install": [ { "id": "molt", "kind": "node", "package": "molt-cli", "bins": ["molt"], "label": "Install molt CLI" } ] ``` ### Technical Analysis The setup script globally installs `molt-cli` without specifying an exact version, lockfile, integrity hash, or verified registry. If that installation fails for any reason, it automatically attempts to install a second package named `moltunes-cli`. The fallback package is not declared in `package.json` and is not identified in the manual installation instructions. Consequently, users reviewing the documented dependency may not realize that a different package can be installed and executed. npm packages can define lifecycle scripts, such as `preinstall`, `install`, and `postinstall`, which execute during installation with the privileges of the user running npm. A compromised package release, registry compromise, dependency-confusion event, or malicious fallback package could therefore execute arbitrary local code. Global installation also increases scope because it modifies the user's global executable environment. Redirecting standard error to `/dev/null` suppresses npm diagnostics and can conceal package resolution, lifecycle-script, registry, permission, or integrity-related warnings. ### Attack Path 1. A user follows the project instructions and runs `scripts/setup.sh`. 2. The script checks whether a command named ...[truncated 1397 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Pin a single reviewed package to an exact version rather than accepting the latest registry release. 2. Remove the undocumented `moltunes-cli` fallback. If a fallback is legitimately required, document it, pin it, and subject it to the same review and integrity controls. 3. Use a lockfile and verify npm integrity metadata or distribute a separately signed and verified release artifact. 4. Explicitly require the expected HTTPS npm registry and reject unexpected registry configuration. 5. Avoid global installation where possible. Prefer a project-local dependency invoked through a controlled wrapper. 6. Do not suppress npm error output. Fail closed and show the user the exact installation failure. 7. Consider disabling lifecycle scripts during installation where operationally possible, then explicitly run only reviewed setup actions. 8. Warn users not to run the installer with `sudo` or another privileged account. 9. Verify the installed executable's package origin and version before reporting that the CLI is ready. ]]>
