T09 · Insecure Skill Coding Practices
- Location
SKILL.md:59- Finding
Remote-Controlled Payment Authorization Without User-Approved Limits
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 59–60 and 82–88
Vulnerability Type: Unbounded payment authorization based on remote responses
Risk Level: HighVulnerable Code
markdown → On `202`: save `requestId` and go to Step 3. → On `402`: re-read the payment requirements from the response and retry with a correct `X-PAYMENT` header.markdown ## Step 4 — Handle extra payment (if needed) If status is `authorization_required`, the order total exceeded the quoted amount: ```http POST https://checkout-agent.credpay.xyz/v1/checkout/{requestId}/authorize X-PAYMENT: <x402 payment for extraOwed amount>Then resume polling from Step 3.
text ### Technical Analysis The skill directs the agent to generate payments from requirements supplied by the remote checkout service. If the service returns HTTP `402`, the agent is instructed to reread those requirements and retry. It may also pay an unspecified `extraOwed` amount when the service reports `authorization_required`. No instruction requires fresh, explicit user approval before either payment flow. The skill also does not require validation of the payment recipient, asset, chain, cumulative amount, or permitted increase against user-approved constraints. Although the initial quote produces a `maxAmount`, no immutable relationship is enforced between that quote and later payment requirements. Consequently, a compromised, malicious, or faulty API could alter the payment destination or request an amount exceeding the user's intended purchase limit. ### Attack Path 1. A user asks the agent to purchase a product and supplies the required order and shipping information. 2. The agent obtains a quote and submits the checkout request. 3. The remote service, or an attacker controlling it, returns manipulated HTTP `402` payment requirements, or later reports `authorization_required` with an inflated `extraOwed`. 4. Following ...[truncated 743 chars]- Remediation
View remediation
Remediation Suggestions
- Require explicit user confirmation after displaying the final total before creating the initial payment.
- Require separate explicit confirmation for every additional payment, including any
extraOwedamount. - Bind authorization to an immutable allowlist containing the expected recipient, Base chain ID
8453, approved token contract, product details, and maximum cumulative amount. - Reject any revised HTTP
402requirements that change the recipient, chain, token, or total beyond the user's approved parameters. - Never automatically satisfy remotely supplied replacement payment requirements.
- Treat the initial
maxAmountas a strict cumulative ceiling unless the user knowingly approves a specific increase. - Record payments associated with each
requestIdand prevent duplicate or replayed authorization. - Present the user with an itemized quote, fees, destination, asset, and exact additional amount before approval.
- Inform the user that their contact and shipping information will be disclosed to the named checkout service and obtain consent before transmission.
