T08 · Insecure Dependencies
Warning
- Location
sandbox.md:8- Finding
Unpinned Third-Party Package Execution Through npx
- Content
View full analysis
``` `sandbox.md:8`: ```bash npx clawhub install --dir /tmp/skill-test/ ``` `compare.md:7-8`: ```bash npx clawhub install skill-a --dir /tmp/compare/skill-a npx clawhub install skill-b --dir /tmp/compare/skill-b ``` ### Technical Analysis The documented commands invoke `clawhub` through `npx` without pinning an audited package version or verifying package integrity. If the package is not already available locally, `npx` can retrieve it and execute package-controlled code from the configured package registry. This creates a supply-chain trust boundary before the candidate skill is placed in its intended isolated directory. The directory supplied through `--dir` isolates the installed skill's files, but it does not inherently isolate the `npx` process or the package manager code executing on the host. A compromised publisher account, malicious package release, registry substitution, dependency compromise, or unsafe registry configuration could therefore cause arbitrary package code to execute with the permissions of the user running the documented command. ### Attack Path 1. An attacker compromises the `clawhub` package, one of its executable dependencies, its publisher account, or the package source selected by the user's registry configuration. 2. The attacker publishes a malicious version while retaining the expected package name. 3. A user follows the documentation and runs an unversioned command such as `npx clawhub install ...`. 4. `npx` resolves and downloads the attacker-controlled or compromised release. 5. Package lifecycle behavior or the resolved command executes on the host before candidate-skill isolation provides protection. 6. The malicious code acces ...[truncated 916 chars]- Remediation
View remediation
install --dir /tmp/skill-test/ ``` 2. Lock and verify the expected package integrity using a trusted lockfile, registry integrity metadata, or an independently distributed checksum. 3. Configure and document an explicit trusted package registry. Do not silently rely on arbitrary user-level registry configuration. 4. Prefer a preinstalled, locally verified `clawhub` executable over downloading and executing a package during each test. 5. Run package retrieval and installation inside an operating-system sandbox or disposable container with: - No mounted personal or project directories unless strictly required. - No inherited API keys, package tokens, SSH credentials, or cloud credentials. - A non-privileged user. - A read-only base filesystem where practical. - Restricted or disabled outbound network access after package retrieval. - Explicit resource and process limits. 6. Review the selected package version and its dependency tree before execution. Revalidate after every version change. 7. Validate skill slugs against a strict allowlist pattern before using them in command arguments or filesystem paths. Reject path separators, `..`, shell metacharacters, and absolute paths. 8. Clarify in the documentation that installing into a temporary directory does not itself sandbox the package manager or protect the host from package lifecycle execution. ]]>