T08 · Insecure Dependencies
Warning
- Location
README.md:23- Finding
Unpinned Third-Party Package Execution in Installation Instructions
- Content
View full analysis
--skill exchange-rate ``` ### Technical Analysis The documented installation command invokes `npx` without pinning the `skills` package to a reviewed version. Depending on the local npm configuration and cache state, `npx` can retrieve the package from the configured npm registry and immediately execute its command-line code. Because neither an exact version nor an integrity value is specified, the code executed during installation can change after this project has been reviewed. Compromise of the package, its publisher account, the configured registry, or an upstream dependency could therefore introduce malicious code into the installation process. This issue is in the installation guidance rather than the skill's runtime script. The audited `scripts/exchange_rate.mjs` file does not install packages or execute local subprocesses. ### Attack Path 1. An attacker compromises the publisher account, package, dependency chain, or registry source used to resolve the unpinned `skills` package. 2. The attacker publishes or serves a malicious package version containing hostile CLI or lifecycle behavior. 3. A user follows the README and runs: ```bash npx skills add --skill exchange-rate ``` 4. `npx` resolves and downloads the mutable package version from the configured registry. 5. The malicious package code executes with the privileges of the user running the installation command. 6. That code can access resources available to the user, such as project files, environment variables, developer credentials, and writable configuration locations. ### Impact Assessment Successful exploitation provides arbitrary code execution in the installing user's security context. The resulting scope depends on that user's privi ...[truncated 601 chars]- Remediation
View remediation
add --skill exchange-rate ``` Replace the placeholder with a verified immutable version rather than a range or distribution tag. 2. Document the package's official publisher and registry source so users can verify that resolution occurs from the intended namespace. 3. Where supported, verify package provenance and integrity before execution. Prefer lockfiles, registry provenance attestations, checksums, or an equivalent reproducible installation mechanism. 4. Review the pinned package version and its dependency tree before recommending it. 5. Present the non-executing manual installation method as the preferred alternative: - Download or clone a verified project revision. - Verify its commit or release checksum. - Copy the reviewed `exchange-rate` directory into the agent's skill directory. 6. Warn users not to run installation commands with elevated privileges and to avoid registries or npm configurations they do not trust. ]]>