T08 · Insecure Dependencies
- Location
SKILL.md:13- Finding
Automatic Execution of an Unpinned Third-Party npm Package
- Content
View full analysis
[args] ``` The same unpinned package is used for sensitive financial operations: ```bash npx -y ceaser-mcp shield 0.001 npx -y ceaser-mcp notes npx -y ceaser-mcp unshield 0x742d35Cc6634C0532925a3b844Bc9e7595f2bD18 npx -y ceaser-mcp import eyJzIjoiMTIzLi4uIn0= npx -y ceaser-mcp help ``` It is also configured as a persistent MCP tool entry: ```bash claude mcp add --transport stdio ceaser -- npx -y ceaser-mcp ``` ### Technical Analysis The Skill instructs the Agent to execute `ceaser-mcp` using `npx -y` without specifying an exact version or package integrity value. The `-y` option suppresses the installation confirmation, while the omitted version allows npm to resolve the package version available from the configured registry at execution time. Consequently, the effective code executed by the Skill can change after the Skill itself has been reviewed. The package source is not included in the audited project, so its implementation, transitive dependencies, lifecycle scripts, note-file permissions, transaction construction, and outbound network behavior cannot be verified from this artifact. This is particularly sensitive because the package is entrusted with: - Generating shielding and unshielding proofs. - Reading and writing private note data. - Constructing unsigned financial transactions. - Receiving destination addresses. - Submitting unshielding proofs to a facilitator. - Running as an MCP server with the permissions of the Agent process. No evidence establishes that the current package is malicious. The vulnerability is the unsafe and mutable trust boundary created by automatic execution of an unpinned external dependency. ### Attack Path 1. An attacker compromises the npm package publisher, registry account, packag ...[truncated 1457 chars]- Remediation
View remediation
``` The example version must be replaced with a version that has actually undergone security review. 2. Prefer installing from a lockfile-backed local project rather than resolving the package dynamically on every invocation. 3. Record and verify package integrity using npm lockfile integrity hashes or an equivalent artifact-verification mechanism. 4. Vendor the package source or include its reviewed source in the audit scope so that proof generation, file handling, transaction construction, and network behavior can be inspected. 5. Review all transitive dependencies and package lifecycle scripts. Disable lifecycle scripts during installation where compatible with the package. 6. Run the package in a restricted environment with: - A dedicated low-privilege account. - Minimal filesystem access. - No unrelated credentials in the environment. - Restricted outbound network access. - Access only to the files required for the requested operation. 7. Before signing or broadcasting any transaction, independently verify: - Chain ID. - Contract address. - Recipient address. - ETH value. - Function selector and decoded calldata. - Fee calculation. - Asset identifier. 8. Avoid configuring an unpinned `npx` command as a long-lived MCP server. Configure a locally installed, integrity-verified executable instead. ]]>
