T09 · Insecure Skill Coding Practices
- Location
SEND.md:20- Finding
Authenticator Code Exposed in URL for State-Changing Asset Transfer
- Content
View full analysis
Vulnerability Details
File Location:
SEND.md:20-22
Vulnerability Type: Sensitive authorization data in a state-changing HTTP GET request
Risk Level: HighVulnerable Code:
bash curl http://127.0.0.1:5333/send?code=[code]&chain=[chain]&to_address=[to_address]&token=[token]&amount=[amount]Technical Analysis
The documented endpoint authorizes and initiates an ETH or USDC transfer through an HTTP GET request. Its six-digit authenticator code is placed directly in the URL query string alongside the transfer recipient and amount.
Query strings can be exposed through shell history, process command-line inspection, terminal or agent transcripts, debugging output, and HTTP access logs. Although the endpoint is bound to loopback, other local processes or users with sufficient process visibility may observe the URL. Plain HTTP also provides no application-layer transport protection, though loopback binding limits network exposure.
GET requests should be safe and idempotent, but this endpoint causes an irreversible financial operation. Using GET increases the possibility of unintended invocation by automated tooling, retries, URL handling, or prefetch behavior. The documentation states that the code remains valid for five minutes and can be used once, leaving a limited but material exploitation window.
Attack Path
- A legitimate user provides an authenticator code and requests an ETH or USDC transfer.
- The agent executes the documented
curlcommand, placing the code and transaction parameters in the process command line and potentially in logs or transcripts. - A local process, local user with process visibility, monitoring component, or party with access to generated logs captures the URL before the code expires.
- The attacker submits a request to the loopback service using the exposed authorization code, potentially replacing the recipient, token, or amount if the code is no ...[truncated 807 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the state-changing GET endpoint with an authenticated POST endpoint.
- Transmit the authenticator code and transaction data in the request body rather than the URL.
- Prefer a permission-restricted Unix-domain socket for local IPC. If HTTP is required, use authenticated TLS even for deployments where loopback exposure assumptions may change.
- Cryptographically bind each authorization to the exact chain, token, recipient address, amount, nonce, and short expiry. Reject any request whose transaction details differ from those approved by the user.
- Require explicit user confirmation that clearly displays the normalized recipient, token, chain, amount, and estimated fees before submission.
- Redact authenticator codes and other authorization material from process output, application logs, agent transcripts, telemetry, and error messages.
- Add
Cache-Control: no-storeand reject GET requests for all state-changing operations. - Enforce strict single-use semantics, rate limiting, short expiration, replay protection, transaction limits, and audit logging that omits secrets.
- Pass request bodies through standard input or a protected temporary descriptor so secrets do not appear in command-line arguments.
