T08 · Insecure Dependencies
Error
- Location
- SKILL.md:49
- Finding
- Unpinned Third-Party CLI Installation and Execution<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:49-52` and `SKILL.md:77` **Vulnerability Type**: Unpinned executable dependency and mutable supply-chain source **Risk Level**: High ### Vulnerable Code ```bash npm i -g @iqinghu/qhkit ``` The Skill also recommends executing the package through `npx` without an exact version: ```bash npx @iqinghu/qhkit <command> ... ``` Its upgrade procedure explicitly installs the mutable latest release: ```bash npm i -g @iqinghu/qhkit@latest ``` ### Technical Analysis The Skill installs and executes `@iqinghu/qhkit` without pinning an audited version or verifying package integrity. Both the unversioned installation and the `@latest` upgrade resolve to mutable package content at execution time. The suggested `npx` fallback can likewise download and execute a package version that was not present during this audit. An npm package can run code through lifecycle scripts during installation and through its installed CLI afterward. Because the implementation of `@iqinghu/qhkit` is not included in this project, its behavior cannot be verified from the audited artifact. A future malicious or compromised release could therefore execute arbitrary code under the account invoking the Skill. The optional use of `https://registry.npmmirror.com` introduces an additional supply-chain trust point. No evidence establishes that the current package or mirror is malicious; the vulnerability is the absence of version and integrity controls around executable third-party content. The Node.js download pipeline at `SKILL.md:56-59` is not a `curl | bash` execution chain. It downloads a fixed archive and verifies it using the publisher-provided checksum list before extraction. That behavior is safer than direct remote script execution, although independently pinning the expected digest would provide stronger protection. ### Attack Path 1. An attacker compromises the npm package maintainer account, package registry entry, distrib ...[truncated 1752 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Pin `@iqinghu/qhkit` to a specific, reviewed version rather than using an unversioned package or `@latest`: ```bash npm install -g @iqinghu/qhkit@<audited-version> ``` 2. Publish the expected npm integrity digest for the approved package tarball and verify it before installation. Maintain a lockfile or controlled installation manifest where practical. 3. Remove automatic upgrade instructions that install `@latest`. Require explicit user approval and security review before changing the approved version. 4. Avoid unpinned `npx` execution. If `npx` is necessary, specify the exact reviewed version and prevent silent substitution: ```bash npx --yes @iqinghu/qhkit@<audited-version> <command> ``` 5. Use the official npm registry as the default trusted source. If a mirror is required, document its trust assumptions and verify that the retrieved package has the same expected integrity digest. 6. Disable npm lifecycle scripts during installation where the package supports operation without them: ```bash npm install -g --ignore-scripts @iqinghu/qhkit@<audited-version> ``` 7. Run the CLI in a restricted environment with access only to the media files required for the task. Do not expose unrelated home-directory content, credentials, or broad filesystem mounts. 8. Store the API token with restrictive permissions, avoid placing it directly in command history, and rotate it if dependency compromise is suspected. 9. Preserve the existing Node.js archive checksum verification, but pin the expected SHA-256 digest independently in the Skill rather than trusting a checksum file retrieved from the same origin as the archive. ]]>