T08 · Insecure Dependencies
Warning
- Location
SKILL.md:46- Finding
Unpinned npm Package Execution in the Documented Publishing Workflow
- Content
View full analysis
xxx.html ``` ### Technical Analysis The documented workflow invokes the `wenyan` npm package through `npx` without specifying an exact version, lockfile, integrity hash, or verified source. Depending on the local npm configuration and installed packages, `npx` may retrieve the currently resolved package version from the configured npm registry and immediately execute its CLI code. This creates a supply-chain trust boundary: the code executed by users can change after the Skill has been reviewed. If the package, a transitive dependency, its maintainer account, or the configured registry is compromised, following the documented workflow could execute attacker-controlled code. Leaving the renderer version unconstrained is not required for the Skill's declared typography and formatting functionality. The command is not independently malicious, and exploitation requires compromise or malicious substitution of the resolved dependency. Nevertheless, executing an unpinned package directly from a registry is an unsafe dependency practice. ### Attack Path 1. An attacker compromises the `wenyan` package, one of its transitive dependencies, a package maintainer account, or the npm registry used by the victim. 2. The attacker publishes or serves a malicious package version that satisfies the unconstrained package reference. 3. A user follows the workflow in `SKILL.md` and runs `npx wenyan render -f xxx.md > xxx.html`. 4. `npx` resolves and, when necessary, downloads the attacker-controlled version. 5. Package lifecycle logic or the CLI entry point executes with the permissions of the invoking user. 6. The malicious code can access resources available to that user, alter generated content, read accessible project files, or execute ad ...[truncated 929 chars]- Remediation
View remediation
render -f xxx.md > xxx.html ``` 2. Prefer declaring the renderer in a project manifest and committing the corresponding lockfile so direct and transitive dependency versions remain reproducible. 3. Install dependencies with lockfile enforcement, such as `npm ci`, rather than resolving new versions during each publishing operation. 4. Verify package provenance, maintainer identity, registry configuration, and published integrity metadata before approving the dependency. 5. Disable or carefully review dependency lifecycle scripts where operationally possible. 6. Run rendering in a restricted environment with minimal filesystem access, no unnecessary credentials, and limited network access. 7. Avoid implicit runtime downloads entirely when possible. Use a previously installed, reviewed renderer or a locally controlled rendering implementation. ]]>