T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:37
- Finding
- Unpinned Third-Party CLI Installation and Automatic Upgrade## Vulnerability Details **File Location**: `SKILL.md:6`, `SKILL.md:37-43`, and `SKILL.md:58-64` **Vulnerability Type**: Unpinned and automatically upgraded third-party dependency **Risk Level**: Medium ### Vulnerable Code ```yaml metadata: {"openclaw":{"emoji":"🌍","requires":{"bins":["qhkit"]},"install":[{"kind":"node","package":"@iqinghu/qhkit","bins":["qhkit"]}]}} ``` ```bash npm i -g @iqinghu/qhkit ``` The accompanying instructions also permit installation through an alternate registry or direct execution with `npx`: ```text Default to the official npm registry; if it is slow or times out, add --registry=https://registry.npmmirror.com. Only when global installation fails because of permissions should npx @iqinghu/qhkit <command> ... be used. ``` Automatic upgrades are instructed as follows: ```bash npm i -g @iqinghu/qhkit@latest ``` ### Technical Analysis The Skill installs and executes `@iqinghu/qhkit` without pinning a reviewed version or verifying package integrity. It further instructs the agent to install `@latest` in response to version notices, including upgrade instructions supplied by the existing CLI. npm packages may execute lifecycle scripts during installation, and the installed CLI subsequently runs arbitrary package code. Therefore, the effective code executed by the Skill can change after the Skill itself has been reviewed. Use of an alternate registry adds another distribution party to the trust chain. This is a supply-chain weakness rather than evidence that the current package is malicious. The package name is consistent across the documentation, so no typosquatting or dependency-confusion attack is directly demonstrated. Nevertheless, a compromised publisher account, malicious package release, compromised registry, or altered transitive dependency could introduce executable code. The separately flagged Node.js checksum pipeline is not a `curl | bash` execution pattern. I ...[truncated 1710 chars]
- Remediation
- ## Remediation Suggestions 1. Pin `@iqinghu/qhkit` to a specifically reviewed version in both the metadata installer and all command examples. 2. Verify the package against an expected integrity digest or a controlled lockfile before installation. 3. Remove automatic installation of `@latest`. Require explicit user approval before changing the installed version. 4. Do not blindly execute upgrade commands returned in CLI messages. Validate upgrades against a trusted, documented version policy. 5. Use only an explicitly trusted registry. If a mirror remains supported, document its additional trust implications and verify package integrity independently of the registry. 6. Disable npm lifecycle scripts during installation where compatible, for example with `--ignore-scripts`, and separately review any required installation steps. 7. Prefer a project-local, sandboxed installation over a global installation. Run the CLI with a dedicated low-privilege account or container that can access only the intended media files. 8. Limit token exposure by passing credentials through a narrowly scoped environment and ensuring they are not written to logs, shell history, or broadly readable configuration files. 9. Document the expected package publisher, package version, registry, and checksum so unexpected changes can be rejected before execution.