T08 · Insecure Dependencies
Warning
- Location
SKILL.md:252- Finding
Unpinned Package Execution Through npx
- Content
View full analysis
Install: `npx clawhub@latest install obsidian-knowledge-base` ``` At lines 250–253: ```bash # Method 1: ClawHub npx clawhub@latest install obsidian-knowledge-base ``` ### Technical Analysis The documented installation process invokes `npx` with the mutable `latest` tag. This allows the package version retrieved and executed by the command to change after the skill has been reviewed. The project does not provide an exact audited version, lockfile, package checksum, signature-verification procedure, or other integrity control for this command. Because `npx` can download and execute npm package code, including applicable package lifecycle behavior, the command crosses a supply-chain trust boundary. A future compromised, malicious, or unexpectedly changed release selected by `latest` could execute code that was not present during this audit. The repository itself contains no malicious executable script, and exploitation therefore depends on compromise or malicious modification of the external package or its distribution channel. ### Attack Path 1. An attacker compromises the `clawhub` npm package, a maintainer account, or the relevant package publication channel. 2. The attacker publishes a malicious release and causes the mutable `latest` tag to resolve to it. 3. A user follows the installation command documented in `SKILL.md`. 4. `npx` downloads and executes the attacker-controlled package release. 5. The malicious package performs actions under the privileges of the user running the command. ### Impact Assessment Successful exploitation could allow arbitrary code execution with the installing user's privileges. Depending on that user's access, the malicious package could read or modify files, access environment variables and locally available cred ...[truncated 386 chars]- Remediation
View remediation
install obsidian-knowledge-base ``` 2. Specify the trusted registry or distribution source and verify that it is configured correctly before installation. 3. Publish and verify a cryptographic checksum or signed provenance record for the expected package artifact. 4. Use a lockfile or equivalent immutable dependency record where the installation workflow supports one. 5. Review the resolved package, transitive dependencies, and lifecycle scripts before recommending execution. 6. Prefer installing from a locally reviewed artifact with network access and unnecessary privileges restricted during installation. 7. Update both occurrences of the installation command in `SKILL.md` so the insecure form is not retained in either the metadata or installation section. ]]>