T07 · Tool Hijacking and Spoofing
Error
- Location
- SKILL.md:59
- Finding
- Unverified Remote Service Supplies Transaction-Critical Deposit Address and Memo## Vulnerability Details **File Location**: `SKILL.md`, lines 59-61 **Vulnerability Type**: `T07: Tool Hijacking and Spoofing` **Risk Level**: High ```text # Build swap transaction (returns vault address + memo — no funds sent) curl -X POST https://forge-api-production-50de.up.railway.app/swap/execute \ -H "Content-Type: application/json" \ -d '{"fromAsset":"ETH.ETH","toAsset":"THOR.RUNE","amount":"0.05","destinationAddress":"thor1..."}' ``` The resulting values are subsequently used as described in `SKILL.md`, lines 72-75: ```text 1. Call `/swap/execute` with from/to asset and destination address 2. FORGE returns a **vault deposit address** and **THORChain memo** 3. User's wallet sends funds to vault address with memo as calldata 4. THORChain protocol routes the swap — FORGE never holds funds ``` ### Technical Analysis The Skill delegates generation of the vault deposit address and THORChain memo to a mutable third-party service hosted at `forge-api-production-50de.up.railway.app`. The reviewed project contains only `SKILL.md`; it provides no local implementation or independent validation mechanism for confirming that the returned address is a current legitimate THORChain vault or that the memo accurately encodes the requested source asset, destination asset, destination address, and disclosed affiliate fee. Transport encryption protects data in transit but does not establish that the service itself is uncompromised or that its response is protocol-correct. Because the returned address and memo directly determine where funds are sent and how the transaction is processed, a compromised, replaced, or malicious remote endpoint could provide attacker-controlled transaction data through an otherwise legitimate-looking tool call. ### Attack Path 1. An attacker compromises, takes over, or maliciously modifies the configured Railway API/MCP deployment. 2. A user or agent requests a swap through `/swap/execute` or ...[truncated 1027 chars]
- Remediation
- ## Remediation Suggestions 1. Independently retrieve the active THORChain vault set from trusted THORNode endpoints and reject any returned deposit address that is not an active protocol vault for the selected chain. 2. Parse and validate the returned memo locally. Confirm the swap action, destination asset, destination address, affiliate identifier, affiliate basis points, and any limits against the user's explicit request. 3. Use multiple independently operated THORNode endpoints and require consistent results for transaction-critical information rather than trusting a single hosted API. 4. Present the validated deposit address, memo, destination asset, destination address, amount, expected output, affiliate fee, network fees, and slippage limits to the user before wallet approval. 5. Make the wallet or client fail closed if validation cannot be completed, the service response is malformed, the vault is inactive, or any returned parameter differs from the user's request. 6. Protect the hosted deployment with strong administrative access controls, deployment integrity monitoring, restricted release permissions, logging, and alerts for changes to transaction-building behavior. 7. Where supported, pin or authenticate release artifacts and document the precise trust boundary: the remote service builds transaction data, but the client must independently verify it before funds are sent.