T08 · Insecure Dependencies
- Location
SKILL.md:198- Finding
Unpinned Remote npm Package Is Automatically Downloaded and Executed
- Content
View full analysis
0x742d35Cc6634C0532925a3b844Bc9e7595f2bD18 ``` ```bash npx -y ceaser-mcp import eyJzIjoiMTIzLi4uIn0= ``` ```bash npx -y ceaser-mcp help ``` The same unsafe dependency execution pattern is repeated in the transaction instructions: ```bash # Shield npx -y ceaser-mcp shield 0.001 # List notes to get noteId npx -y ceaser-mcp notes # Unshield npx -y ceaser-mcp unshield ``` It is also used when registering the package as an MCP server: ```bash claude mcp add --transport stdio ceaser -- npx -y ceaser-mcp ``` ### Technical Analysis The Skill directs the Agent to invoke `npx -y ceaser-mcp` without an exact package version or integrity constraint. If the package is not already present in the local npm cache, `npx` can retrieve the package from the configured npm registry and immediately execute it. The `-y` option suppresses the normal installation confirmation. Consequently, the effective executable payload is not fixed by the audited Skill files. It can change when a new package release is published, when registry resolution changes, or if the publisher account, package, registry, or local npm configuration is compromised. The risk is elevated because the package is expected to: - Generate zero-knowledge proofs. - Read and write privacy-note secrets. - Import note backup material. - Construct cryptocurrency transactions. - Select withdrawal recipients and submit settlement requests. - Run persistently as an MCP server with access to the Agent's tool environment. The package source and dependency tree are not included in the audited project, so their implementation and security properties could not be verified. ...[truncated 1762 chars]- Remediation
View remediation
shield 0.001 ``` Do not use version ranges or tags such as `latest`. 2. Verify package integrity using a lockfile, an approved npm cache, or an artifact whose cryptographic digest is validated before execution. 3. Prefer vendoring the reviewed package and its locked dependency tree into a controlled distribution instead of downloading executable code at invocation time. 4. Audit the package source, install scripts, transitive dependencies, proof-generation behavior, note-storage behavior, recipient handling, and network destinations before approval. 5. Remove automatic `-y` installation where feasible. Require explicit user approval before downloading or installing executable dependencies. 6. Separate dependency installation from financial operations. Installation should occur during a controlled setup phase, not while processing a shield or unshield request. 7. Run the package in a restricted environment with: - Minimal filesystem access. - No unrelated credentials in environment variables. - Network egress limited to required, verified endpoints. - A dedicated low-privilege operating-system account or sandbox. 8. Require explicit confirmation that displays the chain, contract, amount, fees, destination address, and transaction data before every financial operation. 9. Pin and verify the command used for MCP registration as well as the CLI commands. Do not register an unversioned package as a trusted MCP server. ]]>
