T08 · Insecure Dependencies
Warning
- Location
``` ### Technical Analysis The skill instructs users to install or execute the `mdstr` npm package without specifying a reviewed version, lockfile, integrity hash, or trusted publisher and repository. Both commands therefore resolve a mutable package version from the npm registry. The `npx mdstr` command is particularly sensitive because `npx` can download and immediately execute package code. The global installation command can also run package lifecycle scripts during installation and makes the resulti ...[truncated 1717 chars]:19- Finding
Unpinned Third-Party Package Installation and Execution
- Content
View full analysis
``` ### Technical Analysis The skill instructs users to install or execute the `mdstr` npm package without specifying a reviewed version, lockfile, integrity hash, or trusted publisher and repository. Both commands therefore resolve a mutable package version from the npm registry. The `npx mdstr` command is particularly sensitive because `npx` can download and immediately execute package code. The global installation command can also run package lifecycle scripts during installation and makes the resulting executable available more broadly in the user's environment. This is a supply-chain weakness rather than evidence that the current `mdstr` package is malicious. Exploitation would require the resolved package, one of its transitive dependencies, or its publishing account to become compromised or otherwise serve hostile code. ### Attack Path 1. An attacker compromises the package publisher, package release process, npm account, or a transitive dependency. 2. The attacker publishes a malicious version that remains compatible with the unversioned package name. 3. A user follows `SKILL.md` and runs `npm install -g mdstr` or `npx mdstr `. 4. npm resolves the attacker-controlled release because no version or integrity value is pinned. 5. Malicious lifecycle or runtime code executes with the privileges of the invoking user. 6. The code can access data and resources available to that user and may leave a globally accessible modified executable when the global installation workflow is used. ### Impact Assessment Successful exploitation could provide arbitrary code execution under the invoking user's account. The accessible scope may include project files, user-readable documents, ...[truncated 413 chars]- Remediation
View remediation
npx --yes mdstr@ ``` 2. Document the expected npm publisher, source repository, and reviewed release so users can verify package identity. 3. Prefer a project-local dependency recorded in `package.json` and a committed lockfile rather than a global installation. 4. Use deterministic installation such as `npm ci` with a reviewed lockfile when integrating the utility into automation. 5. Verify package integrity and provenance before use, including published integrity metadata and npm provenance attestations where available. 6. Review direct and transitive dependencies before updating the pinned version. 7. Disable lifecycle scripts where they are unnecessary and compatibility has been verified, for example with `npm install --ignore-scripts`. 8. Run the conversion utility with least privilege and avoid invoking global npm installation through `sudo` or an administrator account. ]]>