T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:91
- Finding
- Signing Unverified Transactions Supplied by a Remote API<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 91–104 and 286–290 **Vulnerability Type**: The Skill instructs users to sign opaque transactions returned by a third-party API without requiring transaction decoding, simulation, or validation. **Risk Level**: High ### Vulnerable Code ```markdown ### 4. Claim Your Fees ```bash POST https://bagsworld.app/api/agent-economy/external Content-Type: application/json {"action": "claim", "wallet": "YOUR_SOLANA_WALLET"} ``` Returns unsigned transactions. Sign with your private key and submit to Solana. **Full Claim Flow:** 1. Check claimable: `{"action": "claimable", "moltbookUsername": "X"}` 2. Get unsigned transactions: `{"action": "claim", "moltbookUsername": "X"}` 3. Sign each transaction **locally** with your private key (never sent to any API) 4. Submit signed transactions to a Solana RPC endpoint ``` The same unsafe signing guidance is repeated later: ```markdown **How signing works:** 1. You call the API → it returns **unsigned** transaction bytes 2. You sign locally with your wallet (CLI, SDK, hardware wallet) 3. You submit the signed transaction to any Solana RPC 4. At no point does any private key material touch our servers ``` ### Technical Analysis Local signing prevents direct disclosure of the private key, but it does not establish that a transaction is safe. A valid signature authorizes the actual serialized instructions contained in the transaction, regardless of whether those instructions correspond to the advertised fee claim. The remote service controls the unsigned transaction bytes. The Skill does not require the user or invoking agent to: - Decode every transaction instruction before signing. - Verify the invoked Solana program IDs. - Confirm transfer recipients, token mint addresses, amounts, and fee recipients. - Review signer and writable-account privileges. - Reject unexpected account-creation, authority-change, approval, or transfer instructions. - Compare the ...[truncated 2056 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require every returned transaction to be fully decoded and presented in human-readable form before signing. 2. Define an explicit allowlist of expected Solana program IDs and instruction types for the claim operation. Reject all unknown or additional instructions. 3. Validate every referenced account, including recipients, token mints, fee recipients, signer accounts, writable accounts, and program-derived addresses. 4. Verify transfer amounts and expected wallet balance changes against claimable values obtained independently from on-chain state. 5. Simulate the transaction through a trusted Solana RPC endpoint and inspect execution logs, errors, token balance changes, and SOL balance changes before requesting a signature. 6. Reject transactions containing unexpected transfers, approvals, authority modifications, account closures, arbitrary program calls, or excessive fees. 7. Prefer constructing claim transactions locally from documented program instructions and independently verified on-chain data rather than signing serialized bytes supplied by the service. 8. If remote construction is unavoidable, publish a deterministic transaction schema and provide a local verification tool whose output can be independently audited. 9. Update the signing flow to state explicitly that users must never blindly sign a transaction merely because it is unsigned or because signing occurs locally. 10. Continue recommending a dedicated, minimally funded wallet as defense in depth, but do not present it as a replacement for transaction verification. ]]>