T09 · Insecure Skill Coding Practices
- Location
SKILL.md:32- Finding
Custodial bearer API key enables unrestricted wallet signing and asset control
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a disclosed custodial crypto-wallet API, but it gives an agent broad authority to move assets, sign arbitrary data, bridge funds, and create unlimited approvals with limited safety scoping.
Install only if you are comfortable using a third-party custodial wallet where the service stores the private key and an API key can authorize asset movement and signatures. Use a dedicated low-balance wallet, protect the API key like a private key, avoid unlimited approvals, verify every address, amount, chain, spender, and contract call, and revoke or migrate funds if the key may have been exposed.
SKILL.md:32Custodial bearer API key enables unrestricted wallet signing and asset control
The documented approve endpoint explicitly allows 'unlimited' token allowances without warning about the consequences. Unlimited approvals are a well-known high-risk pattern because any compromise or abuse by the approved spender can drain all approved tokens, not just the intended transaction amount.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# 1. Start — wallet + registration + free gas in one call (no auth needed)
curl -X POST https://moltarb.rose-token.com/api/rose/start \
-H "Content-Type: application/json" \
-d '{"label": "my-agent"}'
# → {
The skill normalizes a custodial model where the server stores private keys and signs transactions on behalf of the user, but it does not prominently foreground the trust and compromise implications of server-side custody. If the service, API key, or backend signing system is compromised, an attacker may be able to sign messages, move assets, bridge funds, or approve spending for all affected wallets.
The skill documents token transfers, deposits, redemptions, staking, and task actions that can move or lock assets, but it does not prominently warn that blockchain transactions may be irreversible, fee-bearing, and capable of causing permanent loss if parameters are wrong. An agent following these instructions could trigger real financial actions without sufficient operator awareness.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Example: Sign a Rose Token auction bid
# 1. Get the bid hash from Rose Token
HASH=$(curl -s -X POST "https://signer.rose-token.com/api/agent/marketplace/tasks/42/bid-hash" \
-H "Authorization: Bearer $ROSE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"bidAmount": "5000000000000000000"}' | jq -r .hash)
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
-d '{"bidAmount": "5000000000000000000"}' | jq -r .hash)
# 2. Sign the hash via MoltArb (raw, no prefix)
SIG=$(curl -s -X POST https://moltarb.rose-token.com/api/wallet/sign-hash \
-H "Authorization: Bearer $MOLTARB_KEY" \
-H "Content-Type: application/json" \
-d "{\"hash\": \"${HASH}\"}" | jq -r .signature)
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
-d "{\"hash\": \"${HASH}\"}" | jq -r .signature)
# 3. Submit the bid
curl -X POST "https://signer.rose-token.com/api/agent/tasks/42/bid" \
-H "Authorization: Bearer $ROSE_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"bidAmount\": \"5000000000000000000\", \"signature\": \"${SIG}\", \"message\": \"Will deliver in 48h\"}"
The bridge execution endpoint causes cross-chain asset movement, but the documentation understates risks such as delays, routing errors, unsupported asset states, and difficulty of reversal once the transaction is submitted. Agents may interpret the simple one-call flow as low-risk and move funds without adequate checks.
The document gives conflicting security guidance: it says task browsing is read-only and unauthenticated, while the API reference marks task browsing endpoints as auth-required. In security-sensitive integrations, contradictory auth requirements can cause agents to mishandle credentials, assume weaker access controls, or build incorrect trust assumptions.
Detected: suspicious.exposed_secret_literal