T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- skill.md:24
- Finding
- State-Changing API Operations Rely on an Unsigned Wallet Address as Identity<![CDATA[ ## Vulnerability Details **File Location**: `skill.md`, lines 24-28; state-changing request examples at lines 47-60, 119-131, and 291-298 **Vulnerability Type**: Broken authentication and wallet impersonation **Risk Level**: High The documented authentication model states that no API key is required and that a wallet address is used as identity: ```markdown - **Base URL**: `https://vybes.fun` - **Auth**: No API keys. Wallet address is identity. Rate limiting prevents abuse. - **Token Launch Fee**: FREE (no cost) - **Website Fee**: 0.2 SOL - **Rate Limits**: 10 launches/hour per wallet, 10 predictions/day per wallet ``` State-changing requests consequently contain only a caller-supplied wallet address and no wallet signature, nonce, challenge, session credential, or other proof of key ownership. For example: ```http POST /api/agent/launch Content-Type: application/json { "agentWallet": "YOUR_WALLET_ADDRESS", "name": "My Token", "symbol": "MTK", "description": "A cool token", "imageUrl": "https://example.com/logo.png", "twitterUrl": "https://x.com/mytoken", "telegramUrl": "https://t.me/mytoken", "discordUrl": "https://discord.gg/mytoken" } ``` The website-linking operation is documented similarly: ```http POST /api/token/link-project Content-Type: application/json { "token_id": "TOKEN_UUID", "project_url": "https://my-token.aicre8.app", "wallet": "CREATOR_WALLET" } ``` ### Technical Analysis A Solana public address is public identification data, not an authentication secret. Any caller can learn another user's address from the blockchain and place it in an HTTP request. Rate limiting does not prove possession of the associated private key and cannot prevent impersonation. Under the declared protocol, operations such as token launch, prediction creation, build-job handoff, project linking, and activity lookup do not carry cryptographic proof that the requester controls the supplied wallet. Unless an undocumented server-sid ...[truncated 1973 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require cryptographic proof of wallet ownership for every authenticated or state-changing operation. 2. Implement a Sign-In with Solana-style challenge flow: - Generate a server-side, single-use nonce. - Bind the challenge to the origin, wallet address, intended action, request digest, issuance time, and expiration time. - Require the wallet to sign the exact challenge. - Verify the Ed25519 signature server-side against the supplied public key. - Atomically consume the nonce to prevent replay. 3. Issue a short-lived, secure session token after successful signature verification and bind it to the verified wallet. 4. Never authorize an operation from a wallet address supplied in the request body alone. Derive the acting wallet from the authenticated session. 5. For high-impact operations such as project linking, require an action-specific signature and verify token ownership or creator authority server-side. 6. Retain independent on-chain validation for payments and bets, including destination, amount, mint or market identifier, memo, finality, and transaction uniqueness. 7. Apply rate limits only after authentication and key them to both the verified wallet and abuse-resistant network/device signals. 8. Document the required signature and replay-protection fields in every API example. ]]>