T08 · Insecure Dependencies
- Location
README.md:28- Finding
Unpinned Third-Party Package Execution in Installation Instructions
- Content
View full analysis
Vulnerability Details
File Location:
README.md, lines 28-32
Vulnerability Type: Unpinned package execution and mutable external source
Risk Level: MediumVulnerable Code
markdown ## Installation ```bash npx add https://github.com/wpank/ai/tree/main/skills/testing/testing-patternstext ### Technical Analysis The installation command invokes `npx add`, causing npm to resolve and execute the third-party package named `add`. No exact package version, integrity hash, lockfile, or provenance requirement is specified. Consequently, the code executed by this command can differ between installations. The argument also refers to content on the mutable Git branch `main`, rather than a reviewed commit SHA or immutable release artifact. Changes to that branch can therefore alter the installed content after this Skill has been audited. There is no evidence that the current npm package or referenced repository is malicious. The vulnerability is the unsafe trust model: compromise of the npm package, its publisher account, the source repository, or the referenced branch could turn the documented installation command into a code-execution and supply-chain attack. ### Attack Path 1. An attacker compromises the npm package `add`, its publisher account, or an upstream dependency used by its command-line implementation. Alternatively, the attacker gains permission to modify the referenced repository's `main` branch. 2. The attacker publishes malicious package code or replaces the mutable repository content. 3. A user follows the README and runs the documented `npx add ...` command. 4. `npx` retrieves the package version available at execution time and runs its command-line or lifecycle code. 5. The malicious code executes with the privileges and environment of the installing user. 6. The code can access files, credentials, environment variables, and repositories available to that user, or modify the destin ...[truncated 824 chars]- Remediation
View remediation
Remediation Suggestions
- Avoid executing an implicitly resolved npm CLI package during installation. Prefer non-executable manual installation steps or a purpose-built installer maintained by the project.
- If an npm installer is required, pin it to an exact reviewed version rather than relying on the latest registry resolution.
- Verify the package's publisher, provenance, and integrity before execution. Use a lockfile or verified integrity digest wherever supported.
- Replace the mutable
mainreference with an immutable, reviewed commit SHA or signed release tag. - Publish checksums or signatures for release artifacts and document how users should verify them before installation.
- Run installation tooling with least privilege in an isolated environment, without production credentials or unrelated repository access.
- Document the exact package being executed and explain why it is trusted, allowing users to review the installer before running it.
