T08 · Insecure Dependencies
- Location
SKILL.md:15- Finding
Unpinned Package Execution Through npx
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:15
Vulnerability Type: Unpinned third-party package execution
Risk Level: MediumVulnerable Code
yaml install: "npx clawhub install play-physical-instrument"Technical Analysis
The installation instruction invokes the
clawhubnpm package throughnpxwithout specifying an exact package version or integrity hash. Depending on the local npm configuration and cache state,npxmay download the currently published package and execute its CLI code.This creates a supply-chain risk because the code executed during installation can differ from the code that was available when the Skill was reviewed. A compromised package publisher account, malicious replacement release, or registry compromise could therefore introduce arbitrary code into the installation process.
Attack Path
- An attacker compromises the npm package, its publisher account, or the configured package registry.
- The attacker publishes a malicious version under the package name resolved by
npx clawhub. - A user follows the documented installation command.
npxretrieves the malicious or compromised package version.- Package lifecycle scripts or CLI initialization code execute with the privileges of the user running the command.
- The malicious package can access files, environment variables, credentials, and network resources available to that user.
Impact Assessment
Successful exploitation could result in arbitrary code execution under the installing user's account. The accessible scope would include that user's files, environment variables, development credentials, and network permissions. If the command were run from an elevated shell, the impact could extend to system-wide modification. The file itself does not demonstrate that the current package is malicious; the risk arises from mutable, unpinned package resolution.
- Remediation
View remediation
Remediation Suggestions
- Pin the installer package to an exact, reviewed version, for example by using an explicit version rather than the latest registry release.
- Enforce package integrity verification through a lockfile, cryptographic checksum, signed release, or trusted package provenance mechanism.
- Document and enforce the expected package registry to prevent resolution through an untrusted registry or mirror.
- Review package lifecycle scripts before installation and disable them where they are unnecessary.
- Prefer a reviewed local installer or a distribution mechanism whose contents are immutable after security review.
- Run installation with a non-privileged account and in a sandbox with only the filesystem and network access needed for installation.
