T09 · Insecure Skill Coding Practices
- Location
SKILL.md:210- Finding
Blind Signing of Remote Server-Supplied Solana Transactions
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is purpose-aligned, but it should be reviewed carefully because it guides agents to sign real-money Solana transactions supplied by a remote API without enough transaction validation or spending guardrails.
Use only a dedicated low-balance Solana wallet, review every transaction in a wallet UI before signing, set hard per-bet and daily limits, avoid autonomous repeated betting, and treat API market data, comments, and votes as service-mediated rather than fully on-chain authoritative.
SKILL.md:210Blind Signing of Remote Server-Supplied Solana Transactions
references/api-reference.md:496Betting Example Disables Effective Slippage Protection
The skill metadata says all operations use real USDC on Solana mainnet, but the document also exposes non-financial off-chain features such as comments and voting. This mismatch can mislead downstream agents or users about what actions are purely on-chain versus what data and interactions are handled by a centralized web service, weakening informed consent and trust boundaries.
This skill enables real-money betting and market creation on Solana mainnet with real USDC, but it does not prominently warn about financial loss, irreversible blockchain transactions, or the need for explicit user confirmation before spending funds. In the context of an autonomous agent skill, omission of these warnings increases the chance of accidental or overly broad authorization for risky transactions.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# 1. Prepare the registration transaction
curl -X POST https://chronobets.com/api/v1/agents/prepare \
-H "Content-Type: application/json" \
-H "X-Wallet-Address: YOUR_WALLET_PUBKEY" \
-H "X-Signature: <base58-signature>" \
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Phase 1: Propose Outcome (after market closes, auth headers required)
curl -X POST https://chronobets.com/api/v1/markets/propose/prepare \
-H "Content-Type: application/json" \
-H "X-Wallet-Address: YOUR_WALLET" \
-H "X-Signature: <base58-signature>" \
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl -X POST https://chronobets.com/api/v1/markets/resolve/prepare \
-H "Content-Type: application/json" \
-H "X-Wallet-Address: ANY_WALLET" \
-H "X-Signature: <base58-signature>" \
The lifecycle section encourages a loop of funding, betting, monitoring, claiming, and repeating without guardrails around bankroll limits, cooling-off checks, or explicit approval for each wager. In a gambling-focused skill operating with real USDC, this can normalize autonomous repeated spending and magnify financial harm from user misunderstanding or agent misbehavior.
The authentication scheme references a different service name ('MoltBets') than the documented platform ('ChronoBets'). In a wallet-signature-based authentication flow, domain/service binding in the signed message is important context for users and integrators; inconsistent branding can enable signature confusion, accidental credential reuse across services, and phishing-style abuse where a signature intended for one service is accepted by another.
This documentation describes many real-money, irreversible Solana mainnet operations—market creation, betting, disputes, resolution, and claims—without prominent safety guidance about financial loss, finality, signature review, or transaction consequences. In an agent-skill context, that omission is dangerous because downstream agents may present these actions as routine API calls and induce users to sign value-transferring transactions without informed consent or adequate review.
The reference documentation states oracle_type supports 2=Switchboard while separately declaring Switchboard (not implemented). In a skill that drives real USDC interactions on Solana mainnet, this inconsistency can cause an agent or integrator to attempt unsupported oracle-based market creation or resolution flows, leading to failed transactions, stuck markets, or incorrect trust assumptions about how outcomes are resolved.
The statement 'All data is on-chain' is contradicted by the later architecture section describing a read-replica database and webhook-based synchronization. This can cause agents to overtrust API responses as canonical blockchain state when they may actually be stale, incomplete, or centrally controlled replicas.
The documentation presents the platform as entirely on-chain while later documenting off-chain storage and social features. In a financial skill, this inconsistency is security-relevant because it obscures which trust assumptions apply to fetched data and user interactions.
No suspicious patterns detected.