T09 · Insecure Skill Coding Practices
- Location
SKILL.md:139- Finding
Untrusted API-Generated Transaction Data May Be Signed and Broadcast
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 139–149; related safeguard at line 158
Vulnerability Type:T09: Insecure Skill Coding Practices
Risk Level: HighVulnerable Code:
json { "data": { "to": "0xContract", "calldata": "0x...", "value": "0" }, "next_steps": [ { "action": "sign_and_send", "network": "base" } ] }The only related transaction-validation requirement is:
markdown - Validate on-chain state before signing transactions.Technical Analysis
The Skill instructs agents to obtain the transaction destination, calldata, and native value from the remote Solvera API and then proceed with a
sign_and_sendaction. These fields fully define what a blockchain transaction invokes and what authority the signer grants.Although the documentation tells agents to validate on-chain state, it does not require them to:
- Independently verify the chain ID and destination contract.
- Decode and inspect the returned calldata.
- Allowlist permitted function selectors.
- Compare decoded arguments with the agent's intended operation.
- Verify that the transaction does not create unexpected token approvals.
- Confirm that the native-token value is zero or otherwise expected.
- Simulate the transaction and inspect resulting asset changes.
Obtaining the expected contract address from
/api/configdoes not provide independent verification because the configuration and transaction builder are served by the same trust domain. If that API or its infrastructure is compromised, both responses could be altered consistently.Keeping private keys local, as required elsewhere in the Skill, prevents direct key disclosure but does not prevent misuse of those keys through authorization of a malicious transaction.
Attack Path
- An agent requests a legitimate offer, fulfillment, or other transaction from a documented write endpoint.
...[truncated 1384 chars]
- Remediation
View remediation
Remediation Suggestions
- Store the expected chain ID and verified contract addresses in trusted local configuration rather than relying solely on
/api/config. - Reject any response whose
toaddress does not exactly match an allowlisted, checksummed contract address for the locally selected network. - Decode calldata locally using a pinned, verified contract ABI.
- Allowlist the function selectors appropriate to each requested operation.
- Compare every decoded parameter with the original request and current independently queried on-chain state.
- Enforce an expected native-token
value, normally zero, and reject any unexplained value transfer. - Detect and reject unexpected token approvals, arbitrary external calls, delegate calls, and unlimited allowances.
- Simulate the transaction through an independently selected provider before signing and inspect all expected asset and allowance changes.
- Present the decoded operation, destination, network, asset deltas, and approval changes for explicit authorization before signing.
- Fail closed when calldata cannot be decoded, simulation fails, independently obtained state differs from the API response, or any transaction field is unexpected.
- Document these checks as mandatory requirements rather than relying on the general instruction to validate on-chain state.
- Store the expected chain ID and verified contract addresses in trusted local configuration rather than relying solely on
