T09 · Insecure Skill Coding Practices
- Location
SKILL.md:51- Finding
Server-Generated Financial Transactions Are Signed Without Mandatory Validation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 51-60
Vulnerability Type: Unsafe signing and broadcasting of externally generated blockchain transactions
Risk Level: HighVulnerable Code Snippet:
markdown 4. State `trading`: `POST /api/session/{id}/build-buy-tx` `{ ethAddress, solAmount }` → returns an **unsigned base64 legacy @solana/web3.js Transaction**. Deserialize, sign with YOUR Solana key, send it yourself, then `POST /api/session/{id}/confirm-buy` `{ ethAddress, txSignature }`. The buy is verified on-chain and must be ≥ $25 worth of SOL (your wallet's total debit exceeds `solAmount` by ~1% pump fee + network fees + ~0.002 SOL ATA rent on first buy). 5. `POST /api/session/{id}/vote-hold` `{ holdMinutes: 1-1440 }` within 10 min — the median of all confirmed buyers decides. 6. When the hold elapses (or a majority votes `vote-sell`), state becomes `settling`: `POST /api/session/{id}/build-sell-tx` → sign + send.Technical Analysis
The documented workflow instructs an agent to deserialize, sign, and broadcast Solana transactions generated by a proprietary remote API. It does not require the agent to inspect or validate the transaction before signing.
A Solana transaction can contain instructions unrelated to the stated trade. Relevant fields requiring validation include:
- Program IDs invoked by each instruction
- Source and destination accounts
- Token mint addresses
- Transfer amounts and maximum wallet debit
- Slippage and minimum-output limits
- Fee and treasury recipients
- Account creation and rent charges
- Token approvals or authority changes
- Signer and writable-account flags
- Additional instructions appended to the expected trade
HTTPS protects the transport connection but does not establish that the service itself, its deployment account, or the generated transaction is trustworthy. The claim that the server never sees ...[truncated 1551 chars]
- Remediation
View remediation
Remediation Suggestions
- Decode every transaction into a human-readable instruction list before signing.
- Enforce an explicit allowlist of expected Solana program IDs and reject unknown programs.
- Verify the selected token mint, source wallet, destination accounts, fee recipients, and all account authority changes.
- Calculate the maximum possible wallet debit and reject transactions exceeding the user-approved amount plus a narrowly bounded fee allowance.
- Require explicit minimum-output and maximum-slippage constraints.
- Reject unexpected transfer, approval, authority-change, or additional instructions.
- Confirm that the transaction is associated with the intended session and recently selected coin.
- Present a complete transaction summary to the human wallet owner and require confirmation before signing.
- Prefer locally constructed transactions from independently validated quote data over opaque server-generated transactions.
- Use a dedicated wallet containing only the capital approved for the session rather than a general-purpose wallet.