T09 · Insecure Skill Coding Practices
- Location
SKILL.md:58- Finding
Untrusted HTTP 402 responses can authorize unrestricted cryptocurrency transfers
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 58-68
Vulnerability Type: Untrusted payment parameters and insufficient transaction authorization controls
Risk Level: HighVulnerable Code Snippet:
text ## Step 2: Pay Amounts are in **atomic units** (6 decimals for USDC): `amount: "50000"` = $0.05. Send `amount` microunits of `asset` (USDC) on `network` (Base) to `payTo` from your agent wallet. Ways to pay: - **CDP Agent Wallet** (Coinbase Developer Platform): `cdp wallet transfer` with USDC - **Permit2** (Uniswap-style): approve + permit + transferFrom flow - **Any EVM wallet**: direct USDC ERC-20 transfer Save the transaction hash — it becomes your PAYMENT-SIGNATURE.Technical Analysis
The Skill directs an agent to construct an irreversible wallet transfer from the
amount,asset,network, andpayTofields returned by a remote HTTP service. These values cross an external trust boundary, but the instructions do not require the agent to enforce:- An allowlist of trusted service providers or domains.
- An allowlist of approved recipient wallet addresses.
- Per-transaction, per-provider, or daily spending limits.
- Verification of the expected Base chain ID and canonical USDC contract.
- Authentication or cryptographic integrity protection for payment requirements.
- Binding between the payment, requested resource, operation identifier, and original quote.
- Explicit user approval for new recipients or unusually large payments.
The Skill explicitly describes operation with “no human in the loop.” Consequently, a malicious or compromised service can influence an agent to transfer wallet funds to an attacker-controlled address. The transaction hash transmitted as
PAYMENT-SIGNATUREis public blockchain data and is necessary for the stated settlement workflow; it is not itself a secret. The primary vulnerability is therefore insufficient authorization and validatio ...[truncated 1684 chars]- Remediation
View remediation
Remediation Suggestions
-
Allowlist providers and recipients
- Permit payments only to explicitly approved service domains and wallet addresses.
- Require manual enrollment before trusting a new provider or recipient.
- Reject a payment if the recipient differs from the provider's previously approved address.
-
Enforce strict spending controls
- Define maximum amounts per request, provider, hour, and day.
- Require explicit user approval above a low configurable threshold.
- Use an isolated wallet funded only with the minimum balance necessary for expected operations.
-
Validate blockchain parameters
- Require Base chain ID
eip155:8453. - Require the canonical, checksummed USDC contract address expected by policy.
- Reject unsupported assets, networks, payment schemes, and malformed addresses.
- Parse atomic-unit amounts using integer arithmetic and enforce minimum and maximum bounds.
- Require Base chain ID
-
Authenticate and bind payment requirements
- Accept requirements only over correctly validated HTTPS connections.
- Require signed or otherwise authenticated quotes from approved providers.
- Bind each payment to the exact resource, HTTP method, request digest, recipient, amount, asset, network, expiration time, nonce, and operation identifier.
- Reject stale, replayed, modified, or unexpectedly changed quotes.
-
Harden transaction authorization
- Present the normalized amount, asset, network, recipient, and provider identity before signing.
- Apply wallet-level transaction policies independently of the Skill.
- Avoid unlimited Permit2 or ERC-20 allowances; use narrowly scoped, expiring approvals.
- Require additional authorization for new recipients, quote changes, or repeated payments.
-
Prevent duplicate and repeated charges
- Persist operation identifiers and transaction states.
- Before retrying, verify on-chain settlement and a ...[truncated 148 chars]
-