T08 · Insecure Dependencies
Error
- Location
SKILL.md:13- Finding
Execution of an Unpinned Mutable npm Package
- Content
View full analysis
--app-id --app-secret npx polyv-live-cli@latest account set-default ``` ```bash npx polyv-live-cli@latest setup e-commerce ``` ### Technical Analysis The Skill instructs users or agents to execute `polyv-live-cli@latest` directly through `npx`. When the package is not already present locally, `npx` can retrieve it from an external package registry and immediately execute its code. The `latest` tag is mutable and does not identify the specific package release that was reviewed. Consequently, the code executed during a future invocation may differ from the code available at audit time. The Skill also provides no package integrity hash, lockfile, provenance verification, or trusted-version constraint. This creates a dependency supply-chain risk. Compromise of the package publisher account, package registry, publication process, or a future package release could cause arbitrary code to run under the invoking user's privileges. ### Attack Path 1. An attacker compromises the npm publisher account, release pipeline, package registry entry, or another mechanism controlling the `latest` package release. 2. The attacker publishes a malicious version of `polyv-live-cli` and causes the `latest` tag to reference it. 3. A user or agent follows the Skill and invokes one of the documented `npx polyv-live-cli@latest` commands. 4. `npx` downloads and executes the attacker-controlled package. 5. The malicious package inherits the permissions and environment of the invoking process. 6. During account setup, the package may also receive the PolyV AppID and AppSecret supplied to the command, allowing those credentials to be captured. ### Impact As ...[truncated 892 chars]- Remediation
View remediation
account list ``` 2. Record the dependency in a package manifest and lockfile rather than resolving a mutable release at each invocation. 3. Verify package integrity using the package manager's integrity metadata and a trusted lockfile. 4. Review the selected package version, publisher identity, repository, release provenance, and install scripts before approving execution. 5. Configure trusted registry sources explicitly and prevent fallback to unexpected registries. 6. Use automated dependency monitoring, but require review before updating the pinned version. 7. Where practical, execute the CLI in a restricted environment with minimum filesystem, credential, and network access. 8. Document the expected version and cryptographic digest so users can detect unexpected package changes. ]]>