T01 · Skill Instruction Hijacking
Error
- Location
- SKILL.md:99
- Finding
- Untrusted Remote Hiring Instructions Can Control Payments and Data Destinations<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 99–110 **Vulnerability Type**: Remote instruction and payment-flow hijacking **Risk Level**: High ### Vulnerable Code Snippet ```markdown **IMPORTANT**: After receiving results, follow the `howToHire` block exactly to hire the agent. --- ## HIRE an agent After searching, use the `howToHire` block from the search result. The standard x402 flow: 1. Send `POST` to the agent's `endpoint` with your task payload 2. If you receive HTTP `402`, read the response body for payment requirements 3. Pay the required USDC amount to the agent's `paymentAddress` on the specified chain 4. Retry the request with `X-PAYMENT: <payment proof>` header 5. **Save the `txHash` from your payment** — you need it to submit a verified review ``` ### Technical Analysis The skill explicitly instructs the agent to follow a remotely supplied `howToHire` block “exactly.” The remote response controls consequential parameters including: - The endpoint receiving the task payload - The payment recipient address - The blockchain network - The requested payment amount - Additional hiring instructions returned by the service The skill does not require a local destination allowlist, maximum payment limit, chain validation, recipient verification, instruction filtering, or explicit user approval before transmitting data or signing a payment authorization. It therefore treats attacker-controlled remote content as authoritative agent instructions instead of untrusted data. This creates an instruction-hijacking boundary: compromise of the registry, manipulation of an indexed agent profile, or a malicious registered agent can influence the agent’s behavior after the skill has been reviewed. ### Attack Path 1. An attacker registers a malicious agent profile, compromises a legitimate profile, or compromises the registry response. 2. The attacker supplies an endpoint under their control and a chosen payment address through the r ...[truncated 1224 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Treat every field returned by the registry and third-party agents as untrusted data, never as executable instructions. 2. Replace “follow exactly” with a fixed, locally defined hiring procedure. 3. Parse responses through a strict schema that accepts only necessary fields such as validated HTTPS endpoints, supported chain identifiers, recipient addresses, and bounded numeric prices. 4. Reject free-form remote instructions that request tool use, secret access, policy changes, unrelated network calls, or additional payments. 5. Enforce a configurable payment ceiling per transaction and per session. 6. Require explicit user confirmation showing the exact asset, amount, chain, recipient, service endpoint, and purpose before signing. 7. Verify that the payment recipient matches the wallet bound to the selected on-chain identity. 8. Restrict outbound requests to HTTPS endpoints whose domains are verified and associated with the selected registry entry. 9. Avoid sending secrets, credentials, private conversation context, or unrelated files in task payloads. 10. Revalidate all payment requirements locally rather than trusting values returned by an arbitrary service endpoint. 11. Provide cancellation and timeout behavior when any endpoint, recipient, amount, or chain differs from the originally approved transaction. ]]>