T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:50
- Finding
- Unbounded Automatic Cryptocurrency Spending Through Paid API Retries## Vulnerability Details **File Location**: `SKILL.md:50`, `SKILL.md:78`, `SKILL.md:132-142`, and `SKILL.md:165` **Vulnerability Type**: Automatic financial transactions without confirmation, retry limits, or cumulative spending controls **Risk Level**: High ### Vulnerable Code Snippets ```markdown Make a POST request to the Shadow buy endpoint. This endpoint requires x402 payment — your agent wallet will automatically pay ~$0.10 USDC on Base when the server returns HTTP 402, then retry. ``` ```markdown If you get a non-200 response, try a different country or service code and call buy again. ``` ```markdown **Number doesn't work / site rejects it:** ``` PUT https://extraordinary-charisma-production.up.railway.app/api/smspva/refuse/{orderId} ``` Then go back to Step 2 and buy a new number. **Number is banned by the service:** ``` PUT https://extraordinary-charisma-production.up.railway.app/api/smspva/ban/{orderId} ``` Then buy a new number with a different country. ``` ```markdown - The x402 payment (~$0.10 USDC) is charged per number purchase, not per OTP poll ``` ### Technical Analysis The skill instructs an agent wallet to satisfy an HTTP 402 payment request automatically and retry the original purchase. It does not require the user to approve the payment, verify the exact amount or recipient, or confirm the Base network transaction before signing. The recovery logic directs the agent to make additional paid purchases whenever a request fails, a website rejects a number, or a number is banned. No maximum retry count, per-transaction limit, cumulative budget, or circuit breaker is specified. Consequently, repeated failures can translate directly into repeated cryptocurrency charges. The payment flow relies on the project-specific third-party endpoint `extraordinary-charisma-production.up.railway.app`. Because the remote service controls its HTTP responses and payment challenge, unsafe payment ...[truncated 2123 chars]
- Remediation
- ## Remediation Suggestions 1. Require explicit user confirmation before every paid transaction, showing the exact token, amount, network, recipient, purpose, and estimated fees. 2. Enforce the expected payment terms in code rather than relying on descriptive text. Reject challenges exceeding the approved amount or using an unexpected token, chain, contract, or recipient. 3. Add configurable per-transaction, per-session, and daily spending limits, defaulting to zero until the user authorizes a budget. 4. Establish a strict retry ceiling. Failed, rejected, refused, or banned numbers must not trigger another paid purchase automatically. 5. Add a circuit breaker that stops purchasing after consecutive failures, anomalous HTTP 402 responses, changed payment recipients, or unexpected price changes. 6. Require renewed confirmation before recovery actions that incur another charge. 7. Use an isolated, narrowly funded wallet dedicated to this service. Do not use a wallet containing unrelated assets. 8. Keep the wallet key in a protected signing component and never include it in API headers, request bodies, logs, browser content, or diagnostic output. 9. Pin and verify the service identity and expected payment recipient. Use a documented production endpoint with appropriate transport and certificate validation. 10. Record an auditable transaction ledger containing user authorization, amount, recipient, order ID, and outcome while excluding private keys and other secrets.