T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:25
- Finding
- Payment Authorization Can Be Forwarded to an Arbitrary Configurable Endpoint## Vulnerability Details **File Location**: `SKILL.md`, lines 25-30 and 56-67 **Vulnerability Type**: Unvalidated credential destination and command-line secret exposure **Risk Level**: Medium ### Vulnerable Code ```yaml credentials: - name: MERCATOR_BASE_URL description: API origin. Defaults to https://mercator-entity-evidence.fly.dev. required: false storage: env - name: X_PAYMENT description: Pre-signed x402 payment header (base64-encoded JSON), for the paid route. Produced by whatever signs x402 for your agent. ``` ```bash BASE="${MERCATOR_BASE_URL:-https://mercator-entity-evidence.fly.dev}" # Free preflight — which fields will be attempted, and the price if you buy. curl -sS -X POST "$BASE/v1/entity-evidence/validate" \ -H 'content-type: application/json' \ -d '{"domain":"lido.fi","fields":["legal_name","primary_domain"]}' | jq . # Paid answer — $0.10 USDC on Base, x402. curl -sS -X POST "$BASE/v1/entity-evidence" \ -H 'content-type: application/json' \ -H "X-PAYMENT: $X_PAYMENT" \ ``` ### Technical Analysis The paid request attaches the `X_PAYMENT` authorization header to an endpoint derived entirely from the configurable `MERCATOR_BASE_URL` environment variable. The documented command does not validate that the URL uses HTTPS or that its hostname is the intended Mercator service before transmitting the payment authorization. If an attacker can influence the agent's environment or configuration, the attacker can set `MERCATOR_BASE_URL` to an attacker-controlled HTTP or HTTPS server. When the paid route is invoked, the pre-signed x402 payment data is then disclosed to that server. The practical ability to reuse the authorization depends on the signature's domain separation, request binding, amount restrictions, nonce handling, and expiration. The header value is also expanded directly into a `curl` command-line argument. On systems where process arguments are visibl ...[truncated 1456 chars]
- Remediation
- ## Remediation Suggestions 1. Pin paid requests to the exact trusted HTTPS origin, `https://mercator-entity-evidence.fly.dev`, rather than allowing an unrestricted environment override. 2. If endpoint configurability is required, parse the URL and enforce: - An `https` scheme. - An explicit allowlist of trusted hostnames. - The expected port. - No embedded user information. 3. Validate the final destination immediately before attaching `X-PAYMENT`; never send the header to untrusted origins. 4. Continue avoiding automatic redirects for authenticated requests. If redirects are later enabled, strip the payment header and revalidate the destination before following them. 5. Ensure x402 authorizations are narrowly bound to the intended chain, recipient, amount, endpoint, request parameters, nonce, and short expiration period. 6. Avoid exposing the authorization in process arguments. Supply sensitive headers through a protected temporary configuration or descriptor, with restrictive permissions and immediate cleanup. 7. Clear the payment authorization from the environment after use and ensure that command tracing, debug logs, and error output do not record it. 8. Document that `MERCATOR_BASE_URL` is security-sensitive and must not be populated from untrusted user input.