T08 · Insecure Dependencies
Error
- Location
- SKILL.md:10
- Finding
- Unpinned Third-Party SDK Receives a Raw Wallet Private Key## Vulnerability Details **File Location**: `SKILL.md`, lines 10-20 and 39-48 **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: High The skill installs `@snakey/sdk` without specifying an exact version or integrity hash. It then passes the value of `WALLET_PRIVATE_KEY` directly to this externally maintained SDK, which performs network communication and signs financial transactions. **Vulnerable configuration at lines 10-20:** ```json "openclaw": { "emoji": "🐍", "requires": { "bins": ["node", "npm"], "env": ["WALLET_PRIVATE_KEY"] }, "primaryEnv": "WALLET_PRIVATE_KEY", "install": [ { "type": "npm", "package": "@snakey/sdk", "global": false } ] } ``` **Private-key use at lines 39-48:** ```javascript const client = new SnakeyClient({ serverUrl: 'https://api.snakey.ai', walletAddress: '0x...', privateKey: process.env.WALLET_PRIVATE_KEY }); // Claim free testnet funds ($10 USDC + ETH for gas) await client.claimFaucet(); // Play a game (handles payment, waiting, everything) const result = await client.play('MyBot'); ``` ### Technical Analysis The npm package reference has no exact version constraint or cryptographic integrity value. Consequently, installation can resolve registry content that changes after the skill has been reviewed. This creates a supply-chain trust boundary around a component that receives a reusable wallet private key and is authorized to conduct network and payment operations. The audited project contains only `SKILL.md`; it does not include the SDK implementation. Therefore, the SDK's key handling, transaction validation, destination restrictions, telemetry, and signing scope cannot be independently verified from this artifact. A compromised package release, maintainer account, transitive dependency, or package-registry delivery path could introduce code that reads and transmits the key or sig ...[truncated 1519 chars]
- Remediation
- ## Remediation Suggestions 1. Pin `@snakey/sdk` to a specific, reviewed version rather than allowing mutable package resolution. 2. Enforce lockfile integrity and verify package cryptographic integrity during installation. 3. Audit and vendor the security-critical SDK source, or otherwise make the exact implementation available alongside the skill for review. 4. Replace reusable raw private keys with an isolated signer, hardware-backed wallet, or short-lived session key. 5. Restrict signing authority by chain ID, contract, recipient, token, maximum amount, transaction count, and expiration time. 6. Require explicit confirmation before every mainnet transaction, displaying the network, recipient, token, amount, calldata, and maximum fee. 7. Use a dedicated low-balance wallet with no unrelated assets or existing token allowances. 8. Separate testnet and mainnet configuration explicitly, and reject mainnet execution unless it is deliberately enabled. 9. Review transitive dependencies and use automated dependency monitoring to detect compromised, deprecated, or unexpectedly changed releases.