T08 · Insecure Dependencies
Warning
- Location
- PUBLISH.md:14
- Finding
- Unpinned npm CLI Packages Are Downloaded and Executed## Vulnerability Details **File Location**: `PUBLISH.md:14-15`, `PUBLISH.md:23-26`, `PUBLISH.md:40-49`, `PUBLISH.md:66-68`, `PUBLISH.md:108-123` **Vulnerability Type**: Supply-chain risk from unpinned executable dependencies **Risk Level**: Medium The publishing instructions repeatedly direct users to download and execute the current release of third-party npm packages: ```bash # Registry selection npx molthub@latest npx clawhub@latest # Inspect commands npx molthub@latest --help npx clawhub@latest --help # Authentication and publication npx molthub@latest login npx clawhub@latest login npx molthub@latest publish npx clawhub@latest publish # Installation npx molthub@latest install clawra npx clawhub@latest install clawra # Documented publication history npx molthub@latest publish --slug clawra --tag latest ``` ### Technical Analysis `npx` can download a package from the configured npm registry and immediately execute its entry point. Using the mutable `latest` tag means the code executed by these commands can change after the skill has been reviewed. No exact package version, lockfile, package integrity value, or other verification mechanism is specified. This creates a supply-chain boundary in which the effective executable is controlled by the package publisher and npm registry state at execution time. The risk is especially relevant to the documented `login` and `publish` operations because those processes may have access to registry credentials, authentication tokens, source files, and publication permissions. ### Attack Path 1. An attacker compromises the `molthub` or `clawhub` npm package, its publisher account, or its release process. 2. The attacker publishes a malicious version and assigns it the `latest` tag. 3. A user follows the documented `npx ...@latest` command. 4. `npx` retrieves and executes the changed package with the user's local privileges. 5. The malicious package c ...[truncated 767 chars]
- Remediation
- ## Remediation Suggestions 1. Replace every `@latest` reference with an exact, reviewed version, such as `package@1.2.3`. 2. Record the approved versions in the publishing documentation and update them only through a deliberate review process. 3. Prefer installing the tools as development dependencies under a committed lockfile, then execute the locked binaries through package scripts. 4. Verify package publisher identity, provenance, signatures, and registry integrity metadata before upgrading. 5. Run publishing tools in an isolated environment with only the minimum files and credentials required. 6. Use short-lived, narrowly scoped publication credentials and revoke them after use where supported. 7. Review release diffs before changing the pinned version.