T08 · Insecure Dependencies
- Location
PUBLISH.md:14- Finding
Unpinned npm CLI Packages Are Downloaded and Executed
- Content
View full analysis
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: MediumThe 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 latestTechnical Analysis
npxcan download a package from the configured npm registry and immediately execute its entry point. Using the mutablelatesttag 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
loginandpublishoperations because those processes may have access to registry credentials, authentication tokens, source files, and publication permissions.Attack Path
- An attacker compromises the
molthuborclawhubnpm package, its publisher account, or its release process. - The attacker publishes a malicious version and assigns it the
latesttag. - A user follows the documented
npx ...@latestcommand. npxretrieves and executes the changed package with the user's local privileges.- The malicious package c ...[truncated 767 chars]
- An attacker compromises the
- Remediation
View remediation
Remediation Suggestions
- Replace every
@latestreference with an exact, reviewed version, such aspackage@1.2.3. - Record the approved versions in the publishing documentation and update them only through a deliberate review process.
- Prefer installing the tools as development dependencies under a committed lockfile, then execute the locked binaries through package scripts.
- Verify package publisher identity, provenance, signatures, and registry integrity metadata before upgrading.
- Run publishing tools in an isolated environment with only the minimum files and credentials required.
- Use short-lived, narrowly scoped publication credentials and revoke them after use where supported.
- Review release diffs before changing the pinned version.
- Replace every
