T09 · Insecure Skill Coding Practices
- Location
SKILL.md:5- Finding
Unrestricted EVM Private Key Access Used for Automatic Payment Authorization
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 5–35
Vulnerability Type: Raw private-key exposure and unconstrained automatic payment authorization
Risk Level: HighVulnerable Code
markdown metadata: openclaw: requires: env: - EVM_PRIVATE_KEY primaryEnv: EVM_PRIVATE_KEY homepage: https://apexrunner.ai/signals/volume-analysis emoji: "📉" --- # volume-analysis ## What It Does Volume profile analysis detecting accumulation or distribution patterns. This signal is computed in real time from APEX Runner's live autonomous trading system operating across Kraken, Coinbase Advanced Trade, and Hyperliquid — not from backtests or third-party aggregators. ## When to Use - To confirm breakouts with volume - To detect accumulation/distribution - Before momentum entries ## How to Use The agent makes an x402-authenticated GET request to:https://apexrunner.ai/signals/volume-analysis
text 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/volume-analysis", private_key=os.environ["EVM_PRIVATE_KEY"] ) print(response.json())text ### Technical Analysis The skill requires direct access to `EVM_PRIVATE_KEY` and passes that unrestricted private key to a third-party x402 client. The documentation also states that the client handles payment authorization automatically. A raw EVM private key is a wallet-wide signing credential rather than a narrowly scoped API credential. The documented implementation does not establish: - A maximum amount per payment - A cumulative spending limit - A fixed recipient or contract allowlist - Explicit validation of the requested blockchain net ...[truncated 2404 chars]- Remediation
View remediation
Remediation Suggestions
- Replace direct raw-key access with a constrained signing service or hardware-backed wallet that enforces transaction policy.
- Use a dedicated payment wallet containing only the minimum balance required for expected calls. Never use a primary treasury or personal wallet.
- Enforce an exact chain ID, approved payment token, recipient allowlist, maximum per-call amount, daily cumulative limit, and request-rate limit before signing.
- Require explicit user confirmation whenever a payment is requested, or clearly provide an opt-in bounded-payment policy.
- Validate the complete x402 payment challenge locally, including network, recipient, asset, amount, expiration, and domain binding.
- Pin the x402 dependency to an audited version using integrity-checked lock files. Review its source and transitive dependencies before granting access to wallet credentials.
- Prevent secrets from appearing in logs, exceptions, telemetry, subprocess environments, or HTTP payloads. Restrict environment-variable access to the smallest possible process.
- Add controls against retries and replay, including unique request identifiers, authorization expiration, and idempotency enforcement.
- Document the exact payment recipient, expected chain, token, maximum price, and authorization process so users can verify each transaction.
- Revoke and rotate the wallet credential immediately if there is any indication that the private key has been logged, transmitted, or exposed to an untrusted component.
