T08 · Insecure Dependencies
Warning
- Location
- scripts/xhs-cover.sh:7
- Finding
- Unpinned Third-Party npm Package Execution## Vulnerability Details **File Location**: `scripts/xhs-cover.sh:7` **Vulnerability Type**: Unpinned dependency execution through `npx` **Risk Level**: Medium ### Vulnerable Code ```bash exec npx xhscover "$@" ``` The documentation also instructs users to execute the same unpinned package in `SKILL.md:22,30,36,39,42` and `README.md:39,62,65,68,71`. ### Technical Analysis The wrapper invokes `xhscover` through `npx` without specifying an exact package version or enforcing a previously installed, integrity-verified local dependency. If no suitable local executable is available, `npx` may resolve and download the current package published under that name, then execute its code. This creates a mutable supply-chain execution path: the code reviewed in this repository does not fully determine the code executed at runtime. A malicious or compromised future package release could therefore execute within the local process context. The repository contains no lockfile or integrity metadata that constrains package resolution. Argument boundaries are correctly preserved by `"$@"`; no shell command-injection issue was identified in the wrapper itself. ### Attack Path 1. An attacker compromises the `xhscover` npm package, its publisher account, or its release process. 2. The attacker publishes a malicious package version under the existing package name. 3. A user or Agent invokes `scripts/xhs-cover.sh` on a system where the package is not pinned and locally installed. 4. `npx` resolves and obtains the mutable package version from the configured npm registry. 5. npm lifecycle logic or the package executable runs with the privileges of the invoking user. 6. The malicious package can access resources available to that user before optionally continuing the expected cover-generation behavior to reduce detection. ### Impact Assessment Successful exploitation permits arbitrary code execution with the privileges of the user running ...[truncated 504 chars]
- Remediation
- ## Remediation Suggestions 1. Pin `xhscover` to an audited exact version rather than resolving the registry's current release. 2. Declare the package in a `package.json` and commit a lockfile containing registry URL and integrity metadata. 3. Install dependencies during a controlled deployment phase using a lockfile-enforcing command such as `npm ci`. 4. Invoke only the installed local binary, for example with `npx --no-install xhscover "$@"` or an explicit path under `node_modules/.bin`. 5. Disable unnecessary npm lifecycle scripts during installation where compatible with the package. 6. Review dependency updates before changing the pinned version, and use registry provenance, integrity verification, and automated dependency scanning. 7. Run the skill with least privilege and restrict access to unrelated credentials and sensitive files.