T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:5
- Finding
- Unbounded Automatic Cryptocurrency Payments Using an Environment-Held Private Key<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:5-9`, `SKILL.md:25-40`, and `SKILL.md:52-60` **Vulnerability Type**: Automatic payment authorization without spending safeguards **Risk Level**: Medium ### Vulnerable Code ```yaml metadata: openclaw: requires: env: - EVM_PRIVATE_KEY primaryEnv: EVM_PRIVATE_KEY ``` ```markdown The x402 client handles payment authorisation automatically. No API key, no account, no subscription required — just an EVM wallet with USDC on Base mainnet. ```python # Example using the x402-python client from x402.client import x402_get response = x402_get( url="https://apexrunner.ai/signals/grid-levels", private_key=os.environ["EVM_PRIVATE_KEY"] ) print(response.json()) ``` ``` ```markdown ## Pricing **$1.00/call** — standard price Early adopters automatically receive 30% off ($0.70/call) until 2026-09-21. Discount tiers apply automatically based on wallet call history: - Early Adopter (0–9 calls): 30% off - Engaged (10–49 calls): 15% off - Loyal (50–199 calls): 15% permanent - VIP (200+ calls): 20% permanent ``` ### Technical Analysis The skill instructs the agent to read a cryptocurrency wallet private key from `EVM_PRIVATE_KEY` and pass it directly to the third-party `x402-python` client. The client then automatically authorizes a paid request to an external service. No explicit user confirmation, maximum authorization amount, cumulative spending limit, request-frequency limit, recipient validation, chain validation, or transaction preview is specified. Consequently, every skill invocation may initiate a cryptocurrency payment without a separate approval step. Repeated, accidental, or attacker-influenced invocations could generate multiple charges. Passing a long-lived private key into an in-process third-party dependency also expands the key's exposure boundary. The reviewed file does not establish that the dependency exfiltrates the key, so key theft is not asserted as a confi ...[truncated 1422 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require explicit, informed user confirmation before every paid request. Display the exact price, token, chain, recipient, and maximum authorization amount. 2. Enforce hard per-call, per-session, daily, and cumulative spending limits locally rather than relying solely on the remote service. 3. Use a dedicated low-balance payment wallet instead of a general-purpose wallet holding unrelated assets. 4. Prefer a scoped signing service or wallet policy that only permits bounded USDC payments to an allowlisted recipient on Base mainnet. 5. Validate the x402 payment challenge before signing, including chain ID, token contract, recipient, amount, expiration, and replay-protection fields. 6. Prevent uncontrolled retries and duplicate payments by applying invocation throttling, idempotency controls, and a strict maximum retry count. 7. Pin the `x402-python` dependency to a reviewed version, verify package provenance and integrity, and audit how it handles private keys. 8. Avoid exposing raw private keys to the application when hardware-backed, isolated, or policy-restricted signing is available. 9. Log payment metadata and authorization outcomes without recording private keys, seed phrases, signatures usable for replay, or other sensitive wallet material. ]]>