T08 · Insecure Dependencies
Warning
- Location
SKILL.md:199- Finding
Unpinned Third-Party Packages Are Retrieved and Executed Through npx
- Content
View full analysis
&1 || npx clawhub login ``` ```bash npx clawhub inspect 2>&1 ``` ```bash npx clawhub publish "$SKILL_DIR" \ --slug \ --name "" \ --version \ --changelog "" ``` Additional unpinned execution and installation instructions occur at `SKILL.md:35`, `SKILL.md:150`, `SKILL.md:241`, and `SKILL.md:283-297`. ### Technical Analysis The workflow repeatedly invokes `clawhub` and `skills` through `npx` without specifying exact package versions or validating package integrity. When a suitable package is not already available locally, `npx` can retrieve package code from the configured npm registry and execute it immediately. Consequently, the code ultimately executed can change after this skill has been reviewed. The workflow does not provide a lockfile, integrity hash, reviewed package archive, trusted registry constraint, or package-signature verification. Some commands also perform global skill installation, increasing the amount of externally supplied content placed in user-controlled directories. This does not establish that the referenced packages are currently malicious. The vulnerability is the unsafe trust model: mutable, unpinned third-party code is executed as part of the documented workflow. ### Attack Path 1. An attacker compromises a referenced npm package, its publisher account, a transitive dependency, or the package source configured in the user's npm environment. 2. The compromised source publishes or supplies a modified version under the expected package name. 3. A user or agent follows the skill and runs an unpinned command such as `npx clawhub publish ...` or `npx skills add ...`. 4. `npx` resolves and retrieves the currently available package rather than a previousl ...[truncated 965 chars]- Remediation
View remediation
... ``` 2. Record dependencies in a project manifest and lockfile rather than resolving mutable versions during each invocation. 3. Verify downloaded package integrity against an independently maintained checksum or trusted package signature. 4. Use a controlled npm registry and explicitly verify the resolved package source before execution. 5. Require informed user confirmation before downloading a package for the first time. 6. Run publishing and installation verification in an isolated container or disposable environment with minimal credentials and filesystem access. 7. Avoid global installation during verification. Install into a temporary, isolated prefix and delete the entire isolated environment afterward. 8. Document and review transitive dependencies whenever the pinned package version changes. ]]>