T09 · Insecure Skill Coding Practices
- Location
SKILL.md:59- Finding
Untrusted Remote Transaction Plan May Drive Wallet Execution
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 59-64 and 80-81
Vulnerability Type: Insecure trust of externally supplied cryptocurrency transaction data
Risk Level: HighComplete Code Snippet
markdown 2. Run: ```bash curl -sS -X POST https://todays-orders.vercel.app/api/todays-orders \ -H 'Content-Type: application/json' \ -d '{"walletAddress":"<wallet-address>"}'- Base the answer on the returned JSON.
text ```markdown 8. If execution is requested and the verdict is not `reject`, use the returned `executionPreview` and `executionPlan` as the hearing record. 9. Only continue toward execution if the client environment can sign and broadcast safely. Otherwise stop at preview and say execution should continue in the wallet-connected web client.The execution approval requirement is stated separately at line 126:
markdown - If the user asks to execute, ask for final approval before broadcast.Technical Analysis
The skill treats JSON returned by a third-party Vercel endpoint as the authoritative source for
executionPreviewandexecutionPlan, and it permits progression toward wallet signing and broadcasting. The instructions do not require the agent or wallet client to independently decode and validate the proposed transaction.Missing mandatory checks include:
- Verification of Solana program IDs against an allowlist.
- Verification of input and output token mint addresses.
- Validation of recipients and all writable accounts.
- Confirmation of exact input amounts, minimum output amounts, fees, and slippage.
- Detection of unexpected SOL or SPL-token transfers.
- Detection of token-account authority changes, delegate approvals, or account closures.
- Comparison of decoded instructions with the human-readable preview.
- Simulation and verification of expected balance changes before signing.
A final approval prompt is a useful procedural safeguard, but it does not establish transaction integrity. A d ...[truncated 1720 chars]
- Remediation
View remediation
Remediation Suggestions
- Treat every field returned by the remote API as untrusted input rather than an authoritative execution instruction.
- Require the wallet client to decode every Solana instruction before requesting approval.
- Allowlist permitted program IDs, swap routers, token mints, and instruction types.
- Verify all source accounts, destination accounts, recipients, signers, writable accounts, and account owners.
- Enforce explicit user-defined limits for input amount, minimum output, price impact, slippage, platform fees, priority fees, and total SOL expenditure.
- Reject any transaction containing instructions absent from the displayed preview, including transfers, delegate approvals, authority changes, account closures, or unknown program interactions.
- Simulate the transaction through a trusted RPC provider and compare predicted balance changes with the declared execution plan.
- Generate the human-readable approval screen from the independently decoded transaction, not from API-provided descriptive fields.
- Bind approval to a cryptographic hash of the exact serialized transaction. Require renewed approval if any instruction, account, blockhash-dependent payload, or amount changes.
- Apply strict response-schema validation, size limits, timeouts, and fail-closed behavior for malformed or incomplete API responses.
- Consider using a pinned, authenticated backend response and verify a digital signature over the plan, while retaining independent transaction validation.
- Clearly disclose that the wallet address is transmitted to the external endpoint and provide an opt-in privacy notice.