other
Error
- Location
- SKILL.md:42
- Finding
- Wallet Private Keys Are Transmitted to a Third-Party Service## Vulnerability Details **File Location**: `SKILL.md:42-46` and `SKILL.md:99-106` **Vulnerability Type**: Private key exfiltration through remote API requests **Risk Level**: Critical ### Vulnerable Code ```bash # 4. Send USDC on Base curl -X POST https://wallet.purpleflea.com/v1/wallet/send \ -H "Authorization: Bearer pk_live_..." \ -H "Content-Type: application/json" \ -d '{"chain":"base","to":"0xRecipient","amount":"10","private_key":"0x...","token":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"}' ``` The documented Monero transaction flow similarly transmits both the view key and spend key: ```json # Monero (requires view + spend keys) { "chain": "monero", "from": "YourXMRAddress", "to": "RecipientXMRAddress", "amount": "1.5", "view_key": "...", "spend_key": "..." } ``` The same insecure interface is also documented in `references/api.md:68` and `references/api.md:107`. ### Technical Analysis The transaction examples instruct an agent to place wallet-control secrets directly into an HTTPS request body sent to `wallet.purpleflea.com`. An EVM private key permits transaction signing for its associated account. A Monero spend key similarly permits spending the corresponding wallet funds. Although TLS can protect the request while it is in transit, it does not protect secrets from the receiving service. The remote server necessarily receives the plaintext key to process the request. The service can log, retain, copy, or misuse it, and a compromise of the service could expose every key submitted through this interface. This design violates the primary non-custodial security boundary: signing keys should remain exclusively under the wallet owner's control. A statement that keys are not stored server-side does not mitigate the fact that they are disclosed to and processed by that server. ### Attack Path 1. An agent follows the documented transaction example. 2. The agent substi ...[truncated 1114 chars]
- Remediation
- ## Remediation Suggestions - Remove `private_key`, `spend_key`, mnemonic, and equivalent wallet secrets from every remote API schema. - Construct and sign transactions locally using audited chain-specific libraries. - Submit only serialized, already-signed transaction bytes to a broadcast endpoint. - Store keys in hardware wallets, platform key stores, hardware security modules, or isolated local signing processes. - Require explicit user confirmation of the chain, asset, recipient, amount, fees, and token approvals before signing. - Prevent secrets from entering command histories, logs, telemetry, crash reports, or agent transcripts. - Rotate all keys previously submitted to this API and transfer remaining funds to newly generated wallets. - Redesign Monero integration so the spend key never leaves the local trusted environment. Disclose the privacy implications before sharing a view key. - Document the trust boundary accurately instead of describing server-side key processing as non-custodial.