T09 · Insecure Skill Coding Practices
- Location
SKILL.md:6- Finding
Unrestricted Private-Key-Based Automatic Payment Authorization
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 6–9, 25–39, and 54–60
Vulnerability Type: Automatic financial authorization using a reusable wallet private key without documented spending controls
Risk Level: MediumVulnerable Code
yaml metadata: openclaw: requires: env: - EVM_PRIVATE_KEY primaryEnv: EVM_PRIVATE_KEYmarkdown 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/oi-divergence", private_key=os.environ["EVM_PRIVATE_KEY"] ) print(response.json())text ```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% permanentTechnical Analysis
The skill requires access to a reusable EVM private key and passes that key directly to the
x402_getclient. The documentation explicitly states that payment authorization is automatic and that each invocation incurs a charge. It does not specify transaction-level user confirmation, an expected maximum charge, cumulative spending limits, invocation rate limits, recipient verification, or the use of a restricted payment credential.A wallet private key provides signing authority rather than narrowly scoped permission to retrieve one signal. Passing it to third-party client code increases the amount of code that handles the secret and makes the consequences of dependency compromise or unsafe runtime behavior more severe. The available project contains no lo ...[truncated 1987 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the general-purpose wallet key with a dedicated payment wallet holding only the minimum funds required for expected usage.
- Prefer scoped session keys, delegated payment credentials, smart-account policies, or another mechanism that restricts the recipient, network, token, per-transaction amount, expiration time, and cumulative allowance.
- Require explicit user confirmation before each payment. Display the destination, network, token, exact amount, and resulting cumulative spend before authorization.
- Enforce a hard maximum charge per request and a configurable daily or session budget. Reject responses requesting payment above the documented price.
- Add invocation rate limiting, duplicate-request protection, and controls preventing automatic retries from producing additional charges.
- Validate the HTTPS destination against an exact allowlist and reject redirects to unapproved origins before any payment is authorized.
- Pin the x402 client to an audited version, verify package integrity, and use a dependency lockfile. Review the dependency's key-handling and payment-validation behavior.
- Keep the private key out of logs, exception messages, telemetry, and response objects. Isolate the signer from the network-facing client where possible so the raw key is not exposed to general dependency code.
- Document key rotation and incident-response procedures, including immediate fund transfer and credential revocation if the signing environment is suspected of compromise.