T08 · Insecure Dependencies
- Location
SKILL.md:44- Finding
Unpinned Third-Party Package Is Downloaded and Executed Through npx
- Content
View full analysis
\ --ai-mode openclaw \ --openclaw-url http://localhost:18789 \ --root ~/vault \ --port 48291 \ --start ``` Lines 98-101: ```bash npx @uchibeke/myway --setup \ --ai-mode openclaw \ --openclaw-url http://localhost:18789 ``` ### Technical Analysis The instructions invoke `@uchibeke/myway` through `npx` without specifying a fixed, previously reviewed version or verifying package integrity. Package resolution can therefore retrieve the current registry release rather than the release that existed when this skill was audited. The downloaded package executes with the privileges of the user running the command. The documented installer performs several security-sensitive operations: creating source files, installing additional dependencies, writing `.env.local`, initializing a database, building the application, and starting a server. npm package lifecycle scripts and the package's own executable may run arbitrary local code during these operations. This creates a supply-chain trust boundary that is not adequately controlled. If the publisher account, npm package, registry resolution process, or a transitive dependency is compromised, the effective code executed by the skill can change without any modification to `SKILL.md`. The audit does not establish that the current package is malicious; the vulnerability is the unpinned and unverified execution mechanism. ### Attack Path 1. An attacker compromises the `@uchibeke/myway` publisher account, package release process, or one of the dependencies installed by the package. 2. The attacker publishes a malicious release under the same package name or introduces malicious lifecycle code into a resolved dependency. 3. A user or AI agent follows the skill a ...[truncated 1357 chars]- Remediation
View remediation
\ --ai-mode openclaw \ --openclaw-url http://localhost:18789 \ --root ~/vault \ --port 48291 \ --start ``` 2. Apply the same explicit version pin to the reconfiguration command. 3. Verify the package artifact before execution using a documented integrity hash, trusted package signature, or independently verified release provenance. 4. Lock transitive dependencies and require reproducible installation from a committed lockfile. Use immutable or frozen-lockfile installation modes where supported. 5. Review package lifecycle scripts and the installer entry point before approving a new package version. Do not automatically advance the pinned version. 6. Require explicit user confirmation before downloading and executing the installer, particularly when the selected root contains sensitive personal files. 7. Avoid providing gateway tokens or other secrets until package authenticity and integrity have been verified. Use narrowly scoped and revocable credentials where authentication is required. 8. Where practical, run the installer in a sandbox, container, or dedicated low-privilege account with filesystem and network access restricted to resources required for installation. ]]>
