T08 · Insecure Dependencies
Warning
- Location
references/setup.md:39- Finding
Unpinned npm Packages Are Downloaded and Executed
- Content
View full analysis
| --exclude-process=] ``` ### Technical Analysis The Skill instructs the Agent to invoke npm packages through `npx` without specifying an exact version, lockfile, or integrity checksum. Package resolution can therefore retrieve a release that differs from the one available when the Skill was audited. Both package runtime code and applicable npm lifecycle scripts execute with the privileges of the Agent user. The `clawpage` parser is also given direct access to a local session log and a project output directory. Consequently, compromise of the npm package, publisher account, registry resolution path, or a future package release could turn an expected conversion operation into arbitrary local code execution. This finding does not establish that either referenced package is currently malicious. The vulnerability is the mutable and unverified dependency execution mechanism. ### Attack Path 1. An attacker compromises the npm package, its publisher account, or the relevant package-resolution path. 2. The attacker publishes a malicious release under the package name used by the unversioned `npx` command. 3. A user invokes the Skill for project setup or session conversion. 4. `npx` resolves and downloads the mutable package release. 5. Package lifecycle or runtime code executes under the Agent user's account. 6. The malicious code can access resources available to that account, including session logs, repository content, environment variables, Git credentials exposed to the process, and w ...[truncated 551 chars]- Remediation
View remediation
{repoName} --dir {localDir} npx --yes clawpage@ parse {sessionPath} \ -o {projectDir}/chats/.tmp/{timestamp}.yaml ``` 2. Prefer installing dependencies from a committed lockfile and running the locally locked binary rather than resolving packages dynamically during every invocation. 3. Verify package provenance, expected publisher identity, source repository, and package integrity before execution. 4. Use npm integrity metadata or an equivalent checksum-verification mechanism where practical. 5. Disable or isolate lifecycle scripts if they are unnecessary. 6. Run conversion in a restricted environment with access only to the selected session and destination directory. 7. Avoid exposing unrelated credentials and sensitive environment variables to the package process. 8. Document a controlled dependency-update and security-review procedure. ]]>