T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:42
- Finding
- Unverified Third-Party Components Handle Wallet Signing## Vulnerability Details **File Location**: `SKILL.md`, lines 42–47 **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Medium **Complete Snippet**: ```markdown 2. **Sign** the EIP-3009 transfer authorization using your wallet private key 3. **Second call** with `X-PAYMENT: <signed-payload>` header → server returns **HTTP 200** with data + `PAYMENT-RESPONSE` settlement receipt **Never fabricate or cache payment tokens.** Each payment nonce is single-use (HTTP 409 on replay). Use the `wallet-keeper` agent (or `x402-fetch` npm package) to handle steps 1-3 automatically. ``` ### Technical Analysis The Skill recommends delegating a financially sensitive EIP-3009 signing workflow to either a `wallet-keeper` agent or the `x402-fetch` npm package. It does not specify a verified publisher, authoritative source, exact package version, integrity hash, signature, or security-review procedure for either component. Because the workflow involves authorization using a wallet private key, resolving the named agent or package to a compromised, spoofed, typosquatted, or malicious implementation could expose signing authority. The repository contains no implementation or dependency manifest through which the actual component and its behavior can be audited. ### Attack Path 1. A user requests data from one of the paid API endpoints. 2. The agent follows the Skill and delegates the x402 challenge-response workflow to `wallet-keeper` or `x402-fetch`. 3. The dependency is obtained or resolved without a pinned version or verified integrity metadata. 4. A compromised or spoofed component receives access to wallet-signing operations or raw wallet credentials. 5. The component exfiltrates the private key, alters the transfer authorization, or requests signatures for an unintended recipient, token, chain, or amount. 6. The attacker uses the stolen key or authorization to compromise wallet funds, subject to the wallet's ...[truncated 588 chars]
- Remediation
- ## Remediation Suggestions 1. Identify the exact approved package or agent using an authoritative registry URL, verified publisher identity, and immutable version. 2. Pin the dependency version and lock its full transitive dependency graph. 3. Verify package integrity with cryptographic hashes or signed provenance before use. 4. Review the component's source code and signing behavior before granting wallet access. 5. Do not provide raw private keys to an agent or general-purpose npm package. Use an isolated wallet service, hardware-backed signer, or restricted signing interface. 6. Have the signer independently validate the chain ID, token contract, recipient, amount, nonce, validity interval, and payment domain before signing. 7. Enforce signer-side per-call and cumulative spending limits rather than relying only on textual guidance or agent behavior. 8. Require explicit user confirmation before every paid request, especially before recurring or automated calls. 9. Restrict the wallet balance and permissions to the minimum required for this API. 10. Log authorization details and settlement receipts without recording private keys or reusable secrets.