T08 · Insecure Dependencies
Warning
- Location
README.md:21- Finding
Unpinned npx Installation Executes Mutable Third-Party Dependencies
- Content
View full analysis
/sci-translation-polish ``` ``` `README_CN.md:93-98`: ```markdown ### Installation ```bash npx skills add xioahu1232/sci-translation-polish ``` ``` ### Technical Analysis The documented installation procedure invokes `npx`, which can download and execute a package resolved from an external package registry. The `skills` CLI is not pinned to a reviewed version, and the referenced skill is not tied to an immutable release or commit hash. Consequently, the code executed by the command can differ from the code that was reviewed during this audit. This creates a supply-chain trust boundary in which package-owner compromise, registry compromise, package takeover, or a malicious future release could introduce attacker-controlled installation behavior. The English example additionally uses an unspecified `` placeholder. If users replace it with an incorrect, untrusted, or typosquatted package owner, they may install a different skill than intended. The repository itself is text-only and does not automatically execute this command. Exploitation requires a user to follow the installation documentation while the remotely resolved dependency or skill source is malicious. ### Attack Path 1. An attacker compromises the package publisher, remote skill repository, registry account, or another source resolved by the installation command. Alternatively, a user selects a malicious or typosquatted owner when replacing the `` placeholder. 2. The attacker publishes a modified version containing malicious installation or runtime behavior. 3. A user runs the documented unpinned `npx skills add ...` command. 4. `npx` retrieves the currently resolved `skills` package, and the CLI r ...[truncated 1081 chars]- Remediation
View remediation
add ... ``` 2. Pin the skill itself to an immutable version, release digest, or commit hash rather than resolving the latest remote state. 3. Replace the `` placeholder with the verified canonical publisher name in all documentation. 4. Document the expected registry and canonical repository so users can detect typosquatted or substituted sources. 5. Publish and verify cryptographic integrity information, such as release checksums, signed tags, provenance attestations, or package signatures. 6. Configure installation tooling to reject unsigned, unexpected, or mutable sources where supported. 7. Advise users not to run the installation command with `sudo` or an administrator account. 8. Recommend reviewing the resolved package version and skill contents before installation, particularly in CI systems or environments containing sensitive credentials. 9. Keep the English and Chinese installation instructions synchronized so both use the same pinned and verified source. ]]>