T09 · Insecure Skill Coding Practices
- Location
SKILL.md:398- Finding
Unvalidated Remote Transaction Data Is Signed with the User's Private Key
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a disclosed OKX swap skill, but it teaches high-impact wallet flows that can approve, sign, and broadcast irreversible transactions without enough validation or confirmation safeguards.
Review this skill carefully before installing. Use it only with wallets and amounts you are prepared to risk, prefer hardware or policy-enforcing signers over raw private keys, require a separate confirmation before any approval and before any swap broadcast, avoid unlimited approvals, and independently verify router/spender addresses and decoded calldata before signing.
SKILL.md:398Unvalidated Remote Transaction Data Is Signed with the User's Private Key
Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.
|-------|-------------|
| `from` | Sender wallet address |
| `to` | OKX DEX router contract address |
| `data` | Transaction calldata (the swap instruction) |
| `value` | Native token amount to send (in wei). `"0"` for ERC-20 swaps |
| `gas` | Estimated gas limit (already padded +50%) |
| `gasPrice` | Gas price in wei |
Without declared permissions the skill's intent is opaque and cannot be validated.
The description markets a 'complete swap flow' using wallet and signing context, but does not prominently warn that the documented flow can perform irreversible approval, signing, and on-chain broadcast actions with private-key-backed credentials. In an agent setting, that omission materially increases the risk of a user invoking the skill without realizing it may move funds or grant token allowances immediately.
The workflow instructs the user/agent to send approval, wait for confirmation, and then send the swap, effectively endorsing multi-step transaction execution without an explicit human confirmation checkpoint between irreversible steps. In an agent context with wallet/signing access, this can enable unintended autonomous fund movement or approvals if upstream parameters are wrong or manipulated.
3. Wait for approval tx to be confirmed
4. Then send the swap transaction
**IMPORTANT**: For native tokens (ETH, BNB, etc. using `0xeeee...eeee`), no approval is needed.
### Step 3: Sign the Transaction
The documentation suggests approving a larger amount such as max uint256 for convenience, but it does not strongly emphasize that unlimited ERC-20 allowances create persistent spending authority that can be abused if the router, spender, or dependent integration is compromised. Because this skill targets live asset movement, normalizing broad approvals meaningfully raises fund-loss risk.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
### Error Handling
- Check `response["code"] == "0"` before processing.
- If broadcast fails, do NOT automatically retry without checking nonce — you may double-spend.
- Common errors:
- `401` = Signature mismatch (check POST signing includes body)
- `429` = Rate limited
The broadcast method submits already signed blockchain transactions but provides no explicit confirmation or irreversible-action warning at the user interface boundary. In a skill whose purpose is full swap execution, this omission increases the risk of accidental on-chain submission, especially when combined with automation or wrappers that treat the function like a routine API call.
The CLI claims to be 'quote only, no signing' but actually calls the swap endpoint, which returns executable transaction calldata. That mismatch can mislead integrators or operators into treating the output as non-executable pricing data, increasing the chance that dangerous calldata is forwarded to a wallet, signer, or downstream automation without the scrutiny normally applied to transaction-building flows.
No suspicious patterns detected.