T08 · Insecure Dependencies
Error
- Location
- SKILL.md:16
- Finding
- Unpinned npm Package Executes with Access to Cryptocurrency Private Keys## Vulnerability Details **File Location**: `SKILL.md:16-38` **Vulnerability Type**: Unpinned third-party dependency with access to high-value credentials **Risk Level**: High ### Vulnerable Code ```bash # For Base export EVM_PRIVATE_KEY="your_base_private_key" # For Solana export SVM_PRIVATE_KEY="your_solana_private_key" ``` Send your first payment: ```bash npx moltycash send KarpathyMolty 1¢ ``` ## Install ```bash # Run directly (recommended) npx moltycash --help # Or install globally npm install -g moltycash ``` ### Technical Analysis The Skill directs users to place raw Base or Solana wallet private keys in environment variables and then execute `moltycash` through an unpinned `npx` command. The command does not specify a reviewed package version, integrity hash, lockfile, or immutable source. Depending on local npm behavior and cache state, `npx moltycash` can retrieve the current package release from the configured npm registry and execute it. That process inherits the caller's environment, including `EVM_PRIVATE_KEY` and `SVM_PRIVATE_KEY`. Consequently, any package version executed this way can read and transmit the private keys or use them to sign transactions. Access to signing material is functionally necessary for the documented payment workflow, but providing an externally retrieved CLI with unrestricted raw private keys is broader than the safer minimum privilege. A restricted signer, hardware-wallet approval flow, or narrowly scoped delegated wallet would reduce the authority exposed to the dependency. The alternative global installation command also introduces a mutable third-party executable into the user's environment. The reviewed project contains no bundled implementation through which the package's behavior could be independently verified. The later recommendation to store credentials in `~/.openclaw/.env` with file mode `600` and directory mode `700` is a reasonable local-ac ...[truncated 2285 chars]
- Remediation
- ## Remediation Suggestions 1. Pin the CLI to a specifically reviewed version instead of executing the latest release: ```bash npx --yes moltycash@2.0.0 --help npx --yes moltycash@2.0.0 send KarpathyMolty 1¢ ``` Version pinning reduces unexpected updates but does not alone establish trust. 2. Publish or include auditable source code, a lockfile, package provenance, and documented release artifacts. Verify registry signatures or provenance and integrity metadata before execution. 3. Prefer a local, locked installation followed by dependency review over downloading code at payment time. Avoid recommending global installation unless operationally necessary. 4. Do not expose a primary or high-value wallet's raw private key. Use a dedicated low-balance payment wallet with only the funds required for the intended transaction. 5. Prefer hardware-wallet signing, an operating-system-backed keystore, an external signer, or a delegated wallet with explicit spending limits. The CLI should request signing without receiving exportable private-key material. 6. Require an explicit confirmation displaying the resolved recipient address, network, token, amount, fees, and total authorization before signing or broadcasting a transaction. 7. Document dependency-verification procedures and warn users that any process launched with these environment variables can access the keys. 8. Retain the recommended `chmod 600 ~/.openclaw/.env` and `chmod 700 ~/.openclaw` controls, while clarifying that filesystem permissions do not protect secrets from authorized processes executed under the same user account. 9. Rotate wallet credentials and transfer remaining assets to a new wallet immediately if an untrusted package version may have received the private key.