T08 · Insecure Dependencies
Warning
- Location
- scripts/xhs-cover.sh:1
- Finding
- Unpinned npm Package Is Downloaded and Executed Through npx## Vulnerability Details **File Location**: `scripts/xhs-cover.sh:1-7` **Additional References**: `SKILL.md:23,29,32,35,38`; `README.md:41,57,60,63,66` **Vulnerability Type**: Unpinned third-party dependency execution **Risk Level**: Medium **Vulnerable code:** ```bash #!/bin/bash # xhs-cover.sh - Xiaohongshu cover generation Skill script # Invokes xhscover through npx and handles registration/login/generation set -e exec npx xhscover "$@" ``` The documentation similarly instructs users to execute unpinned commands such as: ```bash npx xhscover setup npx xhscover generate "5 habits that make you more disciplined" npx xhscover balance npx xhscover history ``` ### Technical Analysis The wrapper executes `xhscover` through `npx` without specifying an exact package version, using a lockfile, validating an integrity hash, or requiring a previously installed local binary. If the package is not available locally, `npx` can download the package version currently resolved by the npm registry and execute its code. This creates a supply-chain trust boundary: the code reviewed in this repository does not fully determine the code that runs when the Skill is invoked. A compromised npm publisher account, malicious package release, registry compromise, or unexpected upstream change could cause arbitrary JavaScript or package lifecycle code to execute under the Agent user's account. Argument forwarding does not independently introduce shell command injection because `"$@"` preserves argument boundaries and prevents shell reinterpretation. The confirmed issue is the mutable, unpinned executable dependency. ### Attack Path 1. An attacker compromises the `xhscover` npm publisher, publishing process, or package distribution channel. 2. The attacker publishes a malicious release under the existing package name. 3. A user or Agent runs `scripts/xhs-cover.sh` or one of the documented `npx xhscover` commands on a system ...[truncated 1062 chars]
- Remediation
- ## Remediation Suggestions 1. Pin `xhscover` to an exact reviewed version instead of resolving the latest available release. 2. Add a `package.json` and committed lockfile containing registry integrity metadata. 3. Install dependencies using a deterministic command such as: ```bash npm ci --ignore-scripts ``` If the package legitimately requires lifecycle scripts, review them before allowing execution rather than enabling them by default. 4. Invoke only the locally installed, locked binary and prohibit network fallback: ```bash exec npx --no-install xhscover "$@" ``` Alternatively, execute `./node_modules/.bin/xhscover` directly after verifying installation. 5. Review upstream source and release changes before updating the pinned version. Use automated dependency scanning and verify package provenance where supported. 6. Run the Skill with least privilege and restrict access to unrelated credentials and sensitive workspace files. 7. Update all commands in `README.md` and `SKILL.md` so users are not instructed to execute an unpinned package directly.