T09 · Insecure Skill Coding Practices
Error
- Location
- references/x402.md:79
- Finding
- Automatic Signing of Externally Supplied x402 Payment Terms<![CDATA[ ## Vulnerability Details **File Location**: `references/x402.md:79-84` **Vulnerability Type**: Automatic authorization of externally controlled payment parameters **Risk Level**: High ### Vulnerable Code ```javascript // 2. Register with x402 — WalletAccountEvm satisfies ClientEvmSigner directly const client = new x402Client(); registerExactEvmScheme(client, { signer: account }); const fetchWithPayment = wrapFetchWithPayment(fetch, client); // 3. Make a paid request — 402 interception, signing, and retry are automatic const response = await fetchWithPayment("https://api.example.com/weather"); const data = await response.json(); ``` ### Technical Analysis The example connects a wallet signer directly to `wrapFetchWithPayment`. When the remote server returns an HTTP 402 response, the wrapper can extract payment requirements, sign an EIP-3009 authorization, and retry the request automatically. The payment amount, recipient, token contract, and network are supplied by external server content. The example does not validate these values against trusted expectations, enforce a maximum payment amount, restrict recipients or token contracts, or obtain fresh human confirmation before signing. This behavior conflicts with the Skill's own controls in `SKILL.md:175-176` and `SKILL.md:207-235`, which require explicit confirmation and prohibit transactions derived from external content. Although EIP-3009 signing does not immediately broadcast a transaction, it creates a transferable authorization that a facilitator can settle on-chain and must therefore be treated as a write operation. ### Attack Path 1. A user or application makes a request through `fetchWithPayment`. 2. The target server is malicious, compromised, redirected, or returns attacker-controlled payment requirements. 3. The server responds with HTTP 402 and specifies an attacker-selected recipient, amount, token, or network. 4. The wrapper accepts the external payment requirements without an a ...[truncated 857 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not expose a wallet signer to automatic 402 handling without a policy-enforcement layer. 2. Parse the payment requirements before signing and validate: - Maximum payment amount - Expected chain identifier - Allowlisted token contract - Allowlisted or explicitly confirmed recipient - Token decimals and symbol - Authorization validity period and nonce 3. Display the complete payment terms and obtain fresh, explicit human confirmation before producing the EIP-3009 signature. 4. Reject payment requirements that differ from terms advertised before the request. 5. Enforce a per-request and cumulative spending limit independent of server-provided values. 6. Use a dedicated wallet with a minimal balance for automated x402 payments. 7. Add tests proving that unexpected recipients, assets, networks, and amounts are rejected before signing. ]]>